答复: RE: about security level evaluation of draft-zhou-6man-mhash-cga-00

zhou.sujing@zte.com.cn Wed, 28 March 2012 11:46 UTC

Return-Path: <zhou.sujing@zte.com.cn>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D1021F8973 for <ipv6@ietfa.amsl.com>; Wed, 28 Mar 2012 04:46:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -94.562
X-Spam-Level:
X-Spam-Status: No, score=-94.562 tagged_above=-999 required=5 tests=[AWL=-1.772, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyM1ViC0VeMg for <ipv6@ietfa.amsl.com>; Wed, 28 Mar 2012 04:46:07 -0700 (PDT)
Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id A91AC21F896D for <ipv6@ietf.org>; Wed, 28 Mar 2012 04:46:06 -0700 (PDT)
Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 286201320096835; Wed, 28 Mar 2012 19:10:43 +0800 (CST)
Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 93082.5338359427; Wed, 28 Mar 2012 19:45:46 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q2SBji2d057872; Wed, 28 Mar 2012 19:45:44 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: <C91E67751B1EFF41B857DE2FE1F68ABA03CCFA91@tk5ex14mbxc272.redmond.corp.microsoft.com>
To: Christian Huitema <huitema@microsoft.com>
Subject: 答复: RE: about security level evaluation of draft-zhou-6man-mhash-cga-00
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <OF414A1785.6C8C6FB1-ONC12579CF.003FC355-C12579CF.00409BA8@zte.com.cn>
From: zhou.sujing@zte.com.cn
Date: Wed, 28 Mar 2012 12:45:33 +0100
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-03-28 19:45:47, Serialize complete at 2012-03-28 19:45:47
Content-Type: multipart/alternative; boundary="=_alternative 00409BA7C12579CF_="
X-MAIL: mse02.zte.com.cn q2SBji2d057872
Cc: "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Mar 2012 11:46:08 -0000

Regards~~~

-Sujing Zhou

Christian Huitema <huitema@microsoft.com> 写于 2012-03-27 23:00:09:

> > Well, I think it is quite a simple trade-off. Increasing Sec 
> increases computational effort on both sides by equal amount. 
> Increasing the length of 
> > the hash increases computational effort only on the attacker side.
> As a result, the hash bits are relatively valuable.
> 
> Jari, the effect of sec is different on both sides. The effort is 
> not increased "by equal amount" but rather "in the same proportion."
> Suppose that an attacker could crack the 59 bit hash in a day with 
> sec=0. Adding sec = 1 means that the attacker will have to try 65536
> times as many keys. The time to crack becomes 65536 hours, i.e. 
> about 7 years. The defender will have to try 65536 instead of one to
> get the right sec, taking only  a fraction of a second. 

after attacker has cracked a CGA address, then it is in the same stand as 
the defender.
defender, as well as attacker, has to try one by one to get the right sec, 
i.e., to get a matching length of zeros,
how come attacker need extra 65536 hours but defender only needs a 
fraction of a second?
 
> > 1) Status quo: RFC 4982 eats three bits for Sec, leaving 59 bits 
> of hash length after accommodating for u and g bits as well. The 
> good with this is 
> > that it leaves maximum size for hash. The bad is that it is less 
> flexible for adding many new hash algorithms.
> 
> I kind of like the status quo.
> 
> > 2) The proposed new approach: Eat a total of six bits, for Sec and
> the hash algorithm identifier. 56 bits remain. The good is that this
> gives more 
> > flexibility to allocate hash algorithms, including the ability to 
> independently choose Sec and the algorithm. The bad is that the hash 
size is 
> > decreased.
> 
> Decreased a lot. On the other hand, if we do gain the flexibility to
> define new algorithms, then we can define a mandatory-to-implement 
> algorithm that incorporates the equivalent of the "sec" strengthening.

the security of a hash algo can be roughly estimated by length of its 
output,
from birthday attack, that is about 2^(59/2) or 2^(56/2)(theorical 
estimate), or less,
can you give a more precise of value of "a lot"?
I don't see flexibility in defining mandatory-to-implementing hash alg 
 
> -- Christian Huitema
> 
> 
> 
>