Subject: Re: Security Area Response to Hash Function "Breaks"

From: Magnus Nyström <[email-masked]>
Date: Thu, 1 Dec 2005 09:48:51 +0100 (W. Europe Standard Time)

That said, I of course would not have anything against a move to, e.g., a 
new DIGEST-SHA256 (even though I personally would have preferred a strong 
password-based authentication/key exchange mechanism such as EKE).

In light of the hash function results, moving away from MD5 and SHA-1 
(with reason) seems prudent practice. My initial posting here had the 
intent of examining whether SACRED faces any direct problems due to the 
results; my conclusion at this time is that SACRED does not.

-- Magnus

On Wed, 30 Nov 2005, Magnus Nyström wrote:

> In the context of Digest-MD5, we're mostly concerned about pre-image 
> resistance. I further assume that the entropy of the underlying password is 
> less than 128 bits.
>
> -- Magnus
>
> On Wed, 30 Nov 2005, Russ Housley wrote:
>
>> Magnus:
>> 
>> The NIST recommendation is to move away from SHA-1 by 2010, simply due to 
>> its size.  NIST made this recommendation before the flaws in SHA-1 were 
>> discovered.  SHA-1 is a 160-bit hash.  MD5 is a 128-bit hash.  Can you 
>> explain why the smaller hash value is acceptable in the SACRED protocol 
>> context beyond 2010?
>> 
>> Russ
>> 
>> At 09:56 AM 11/30/2005, Magnus Nyström wrote:
>> 
>>> Please see below.
>>> 
>>> In light of recent cryptanalytic results on hash functions, each IETF 
>>> working group is asked to provide an analysis of its use of hash 
>>> functions.
>>> 
>>> SACRED rely on DIGEST-MD5, but IMO SACRED does not become vulnerable to 
>>> attacks due to recent results on MD5. The reasons are that in Digest-MD5, 
>>> hashes are either done on nonces provided both by the client and the 
>>> server or on the username and password selected by the client. Hence an 
>>> attacker cannot perform a collision attack - in the former because the 
>>> nonces are not known in advance and in the latter case since it would be 
>>> equivalent to finding the password, at which point he could impersonate 
>>> the user anyway.
>>> 
>>> Comments, anyone?
>>> 
>>> -- Magnus
>>> 
>>> On Thu, 24 Nov 2005, Russ Housley wrote:
>>> 
>>>> Below is a summary of the discussion that occurred at the SAAG session 
>>>> during IETF 64. When MD5 or SHA-1 is used to support digital signatures 
>>>> or used by itself, recent cryptographic research findings indicate the 
>>>> need for a transition.  Therefore, I encourage all IETF WGs to follow the 
>>>> lead of the Security Area in transition away from MD5 and SHA-1 toward 
>>>> SHA-256.
>>>> TCP-MD5 is one example where a transition is needed.  In this case, a 
>>>> transition to HMAC-SHA-1 or HMAC-SHA-256 seems like a reasonable move.
>>>> Russ Housley
>>>> Security Area Director
>>>> = = = = = = = = = =
>>>> During IETF 64, the Security Area Advisors Group (SAAG) session was 
>>>> dedicated to the discussion of hash function "breaks" and the appropriate 
>>>> IETF response to this situation.
>>>> Eric Rescorla from gave a presentation on deploying a new hash function. 
>>>> The presentation is based on a paper that Eric co-authored with Steve 
>>>> Bellovin. All of the IETF security protocols that were analyzed required 
>>>> work in order to support transition to new hash functions.  The paper is 
>>>> available at http://www.cs.columbia.edu/~smb/papers/new-hash.pdf
>>>> Russ Housley gave a presentation on the Security Area response to these 
>>>> hash function "breaks."  We should "walk, not run."  This is not a 
>>>> problem yet, but as the attacks are improved it will become a problem. 
>>>> Russ shared his conclusions from the NIST Hash Workshop held on October 
>>>> 31st and November 1st.
>>>>  * SHA-1 should be reach its "end of life" digital
>>>>    signatures by 2010;
>>>>  * The IETF cannot expect any new standard hash functions
>>>>    before 2010;
>>>>  * The security ADs have decided that we need to transition
>>>>    to SHA-256 now; and
>>>>  * There will probably be another transition once a new hash
>>>>    function is available.
>>>> The IETF needs to become good at transitions as we have at least two. 
>>>> Within the Security Area, protocols with active WGs will be analyzed 
>>>> within those WGs; others will be handled in SAAG.  The following 
>>>> directive to WG Chairs in the Security Area was given:
>>>>  * Perform Bellovin-Rescorla analysis on every protocol in
>>>>    the WG by IETF 65; and
>>>>  * Start standards work on transition to SHA-256, but plan
>>>>    for future transitions.
>>>> In some cases it may be appropriate to transition away from hash 
>>>> functions, perhaps to a message authentication code.
>>> 
>> 
>