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

["Blumenthal, Uri - 0668 - MITLL" <[e-mail]>]

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 – 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 – then a lot of the
currently used mechanisms and primitives need revisiting.
-- 
Regards,
Uri Blumenthal                            Voice: [phone]
Cyber Systems and Technology  Fax:    [phone]
MIT Lincoln Laboratory


From:  "[e-mail]" <[e-mail]>
Date:  Wed, 1 Feb 2012 03:13:07 -0500
To:  Dan Harkins <[e-mail]>
Cc:  "[e-mail]" <[e-mail]>, Steven Bellovin <[e-mail]>
Subject:  [Cfrg] 答复: Re:  [saag] New draft: Hashed Password Exchange

> 
> Hi,all
> 
> [e-mail] 写于 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
>>>>> > >>> [e-mail]
>>>>> > >>> https://www.ietf.org/mailman/listinfo/saag
>>>> > >>
>>> > >
>>> > >
>>> > >       --Steve Bellovin, https://www.cs.columbia.edu/~smb
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > _______________________________________________
>>> > > saag mailing list
>>> > > [e-mail]
>>> > > https://www.ietf.org/mailman/listinfo/saag
>>> > >
>> > 
>> > 
>> > _______________________________________________
>> > Cfrg mailing list
>> > [e-mail]
>> > http://www.irtf.org/mailman/listinfo/cfrg
>> >