Re: Security Area Response to Hash Function "Breaks"

[Magnus Nyström <magnus@xxxxxxxxxxxxxxx>]

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.