[Cfrg] 答复: Re: 答复: Re: [saag] New draft: Hashed Password Exchange

zhou.sujing@zte.com.cn Thu, 02 February 2012 01:22 UTC

Return-Path: <zhou.sujing@zte.com.cn>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31B71F0C40; Wed, 1 Feb 2012 17:22:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -92.29
X-Spam-Level:
X-Spam-Status: No, score=-92.29 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_48=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, RCVD_IN_DNSWL_LOW=-1, 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 As6x55LDGHNq; Wed, 1 Feb 2012 17:22:35 -0800 (PST)
Received: from mx7.zte.com.cn (mx7.zte.com.cn [202.103.147.169]) by ietfa.amsl.com (Postfix) with ESMTP id A61371F0C49; Wed, 1 Feb 2012 17:22:33 -0800 (PST)
Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 5467.3858719218; Thu, 2 Feb 2012 09:22:31 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q121MOlw057426; Thu, 2 Feb 2012 09:22:24 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: <CB4EC84A.A54E%uri@ll.mit.edu>
To: "Blumenthal, Uri - 0668 - MITLL" <uri@ll.mit.edu>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <OF4B334631.C715AF00-ON48257998.0007373A-48257998.00078BA6@zte.com.cn>
From: zhou.sujing@zte.com.cn
Date: Thu, 2 Feb 2012 09:22:10 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-02 09:22:25, Serialize complete at 2012-02-02 09:22:25
Content-Type: multipart/alternative; boundary="=_alternative 00078BA448257998_="
X-MAIL: mse02.zte.com.cn q121MOlw057426
Cc: cfrg-bounces@irtf.org, "cfrg@irtf.org" <cfrg@irtf.org>
Subject: [Cfrg] =?gb2312?b?tPC4tDogUmU6ICC08Li0OiBSZTogIFtzYWFnXSBOZXcg?= =?gb2312?b?ZHJhZnQ6IEhhc2hlZCBQYXNzd29yZCBFeGNoYW5nZQ==?=
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Feb 2012 01:22:37 -0000

Well£¬ it is the requirement of the HMAC for key being long and random.
Then in the case of the draft, ordinary hash is enough I guess? 


Regards~~~


cfrg-bounces@irtf.org дÓÚ 2012-02-01 23:49:13:

> My take on this is: if you believe that a hash-function is a good 
> randomizer and can be used in cryptographic key generation process ¨C
> then  it does not matter whether what you feed as a "key" input to 
> HMAC is uniformly distributed or not (because of HMAC internal "hash
> spins"). And if you are uneasy on how really random your hash output
> is ¨C then a lot of the currently used mechanisms and primitives need
> revisiting.
> -- 
> Regards,
> Uri Blumenthal                            Voice: (781) 981-1638
> Cyber Systems and Technology  Fax:    (781) 981-0186
> MIT Lincoln Laboratory 
> 
> From: "zhou.sujing@zte.com.cn" <zhou.sujing@zte.com.cn>
> Date: Wed, 1 Feb 2012 03:13:07 -0500
> To: Dan Harkins <dharkins@lounge.org>
> Cc: "cfrg@irtf.org" <cfrg@irtf.org>rg>, Steven Bellovin 
<smb@cs.columbia.edu>
> Subject: [Cfrg] ´ð¸´: Re: [saag] New draft: Hashed Password Exchange
> 
> 
> Hi,all
> 
> cfrg-bounces@irtf.org дÓÚ 2012-01-07 17:03:25:
> 
> > 
> > 
> > On Wed, January 4, 2012 2:56 pm, Steven Bellovin wrote:
> > > Good point; let me think about it for -01.  An obvious solution is 
to send
> > > the hostname with the effective password.
> > 
> >   How is that different than using random salt then? If _something_ is
> > going to be sent shouldn't it be a uniformly random bitstring instead 
of
> > a hostname?
> > 
> >   A uniformly random bitstring would be more appropriate as a key to
> > HMAC than a highly structured string like a password too. Iterate
> > HMAC(salt, password | service-URI) instead of HMAC(password, 
service-URI).
> 
> 
> 
> I think Dan's suggestion is reasonable, I checked the RFC 2104 and 
> found the following section :
> 
> "3. Keys
> 
>    The key for HMAC can be of any length (keys longer than B bytes are
>    first hashed using H).  However, less than L bytes is strongly
>    discouraged as it would decrease the security strength of the
>    function.  Keys longer than L bytes are acceptable but the extra
>    length would not significantly increase the function strength. (A
>    longer key may be advisable if the randomness of the key is
>    considered weak.)
> 
>    Keys need to be chosen at random (or using a cryptographically strong
>    pseudo-random generator seeded with a random seed), and periodically
>    refreshed.  (Current attacks do not indicate a specific recommended
>    frequency for key changes as these attacks are practically
>    infeasible.  However, periodic key refreshment is a fundamental
>    security practice that helps against potential weaknesses of the
>    function and keys, and limits the damage of an exposed key.)"
> 
> 
> Since passwords are often not too long, and not so random, it is better 
> to hash it before using it as a key in a HMAC. 
> 
> 
> Regards~~~
> 
> -Sujing Zhou
> > 
> >   That said, goal 4 in the draft-- "By iterating a sufficient number 
of
> > times, dictionary attacks can be made arbitrarily expensive"-- seems a
> > bit misguided. The Amazon cloud service has been used to launch an
> > off-line dictionary attack against the WPA-PSK protocol which uses 
PBKDF2
> > (HMAC-SHA1) with 4096 iterations to obfuscate a password. This attack
> > checks 24,000,000 candidate passwords per minute at a cost of $0.28.
> > That's more than 1,600,000,000 iterations per second for about 1/2 a 
cent.
> > So I don't think increased iteration makes dictionary attacks much 
more
> > expensive.
> > 
> >   Which begs the question, how is this proposal different than PBKDF2?
> > That the "salt" is a service URI?
> > 
> >   regards,
> > 
> >   Dan.
> > 
> > > On Jan 4, 2012, at 5:21 01PM, Joe Touch wrote:
> > >
> > >> Hi, Steve,
> > >>
> > >> This doc doesn't appear to address the case where a host has 
multiple
> > >> DNS names, which could make it difficult to incorporate the 
hostname
> > >> into the transform. I.e., I could contact a mail server at an IP 
address
> > >> that represents any of dozens of DNS names - how does the server 
know
> > >> which one I used so it can match without exhaustively trying all 
its
> > >> equivalent names?
> > >>
> > >> Joe
> > >>
> > >> On 1/4/2012 1:41 PM, Steven Bellovin wrote:
> > >>> I'd appreciate comments on my new draft, 
draft-bellovin-hpw-00.txt:
> > >>>
> > >>> Abstract
> > >>>
> > >>>    Many systems (e.g., cryptographic protocols relying on 
symmetric
> > >>>    cryptography) require that plaintext passwords be stored. Given 
how
> > >>>    often people reuse passwords on different systems, this poses a 
very
> > >>>    serious risk if a single machine is compromised.  We propose a
> > >>> scheme
> > >>>    to derive passwords limited to a single machine from a typed
> > >>>    password, and explain how a protocol definition can specify 
this
> > >>>    scheme.
> > >>>
> > >>>
> > >>>       --Steve Bellovin, https://www.cs.columbia.edu/~smb
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> saag mailing list
> > >>> saag@ietf.org
> > >>> https://www.ietf.org/mailman/listinfo/saag
> > >>
> > >
> > >
> > >       --Steve Bellovin, https://www.cs.columbia.edu/~smb
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > saag mailing list
> > > saag@ietf.org
> > > https://www.ietf.org/mailman/listinfo/saag
> > >
> > 
> > 
> > _______________________________________________
> > Cfrg mailing list
> > Cfrg@irtf.org
> > http://www.irtf.org/mailman/listinfo/cfrg
> > [¸½¼þ "smime.p7s" ±» ÖÜËÕ¾²00132831/user/zte_ltd ɾ³ý]
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg