Re: Security Area Response to Hash Function "Breaks"

[Magnus Nyström <magnus@xxxxxxxxxxxxxxx>]

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.