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

zhou.sujing@zte.com.cn Tue, 27 March 2012 14:54 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 B39E721E816B for <ipv6@ietfa.amsl.com>; Tue, 27 Mar 2012 07:54:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -94.633
X-Spam-Level:
X-Spam-Status: No, score=-94.633 tagged_above=-999 required=5 tests=[AWL=-1.843, 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 9CF7VTjdI4qX for <ipv6@ietfa.amsl.com>; Tue, 27 Mar 2012 07:54:29 -0700 (PDT)
Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 08E5E21E80C3 for <ipv6@ietf.org>; Tue, 27 Mar 2012 07:54:25 -0700 (PDT)
Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 122801320096835; Tue, 27 Mar 2012 22:19:16 +0800 (CST)
Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 34335.3379131713; Tue, 27 Mar 2012 22:54:13 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q2REsDfc071787; Tue, 27 Mar 2012 22:54:13 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: <4F71CD00.8000208@piuha.net>
To: Jari Arkko <jari.arkko@piuha.net>
Subject: =?GB2312?B?tPC4tDogUmU6IGFib3V0IHNlY3VyaXR5IGxldmVsIGV2YWx1YXRpb24gb2Y=?= =?GB2312?B?ICBkcmFmdC16aG91LTZtYW4tbWhhc2gtY2dhLTAw?=
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <OF3DC925E5.93F19BD8-ONC12579CE.0051617F-C12579CE.0051DE03@zte.com.cn>
From: zhou.sujing@zte.com.cn
Date: Tue, 27 Mar 2012 15:54:08 +0100
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-03-27 22:54:17, Serialize complete at 2012-03-27 22:54:17
Content-Type: multipart/alternative; boundary="=_alternative 0051DE01C12579CE_="
X-MAIL: mse02.zte.com.cn q2REsDfc071787
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: Tue, 27 Mar 2012 14:54:30 -0000

Regards~~~

-Sujing Zhou

Jari Arkko <jari.arkko@piuha.net> 写于 2012-03-27 16:21:52:

> 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 
relativelyvaluable.
> 
> The trade-off that we have in front of us is to choose between:
> 
> 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.
> 
> 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.
> 
> FWIW, I'm personally in the camp that #1 is still the right 
> approach. We've have 5 entries left:
> 
> http://www.iana.org/assignments/cga-message-types/cga-message-types.
> xml#cga-message-types-3
> 
> and even if we some day would run out, there would always be an 
> opportunity to use the last bit combination (111) to denote that the
> algorithm value would be elsewhere in the address. I admit that my 

use 111 to denote hash algorithm is somewhere in the address, then where 
they would be,
in the subnet prefix, or in the hash output? and how many bits will it 
occupy?
that will bring us back to the current situcation I think, and worse, with 
3  additional bits
eaten just indicating that "hash algo is somewhere". 


> preferences are affected by my view that 59 bits is only borderline 
> secure. So I wouldn't want to reduce it, if it can be avoided.

59 bits is not enough for a hash, that is why sha-1 has 128 bits and even 
longer,
that is why HASH2 is introduced to compensate for the short hash length 
occupied.
Since then, why cann't we do better?

> 
> Jari
> 
>