Re: Security Area Response to Hash Function "Breaks"

Magnus:

The NIST recommendation is to move away from SHA-1 by 2010, simply=20
due to its size.  NIST made this recommendation before the flaws in=20
SHA-1 were discovered.  SHA-1 is a 160-bit hash.  MD5 is a 128-bit=20
hash.  Can you explain why the smaller hash value is acceptable in=20
the SACRED protocol context beyond 2010?

Russ

At 09:56 AM 11/30/2005, Magnus Nystr=F6m wrote:

>Please see below.
>
>In light of recent cryptanalytic results on hash functions, each=20
>IETF working group is asked to provide an analysis of its use of=20
>hash functions.
>
>SACRED rely on DIGEST-MD5, but IMO SACRED does not become vulnerable=20
>to attacks due to recent results on MD5. The reasons are that in=20
>Digest-MD5, hashes are either done on nonces provided both by the=20
>client and the server or on the username and password selected by=20
>the client. Hence an attacker cannot perform a collision attack - in=20
>the former because the nonces are not known in advance and in the=20
>latter case since it would be equivalent to finding the password, at=20
>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=20
>>session during IETF 64. When MD5 or SHA-1 is used to support=20
>>digital signatures or used by itself, recent cryptographic research=20
>>findings indicate the need for a transition.  Therefore, I=20
>>encourage all IETF WGs to follow the lead of the Security Area in=20
>>transition away from MD5 and SHA-1 toward SHA-256.
>>TCP-MD5 is one example where a transition is needed.  In this case,=20
>>a transition to HMAC-SHA-1 or HMAC-SHA-256 seems like a reasonable move.
>>Russ Housley
>>Security Area Director
>>=3D =3D =3D =3D =3D =3D =3D =3D =3D =3D
>>During IETF 64, the Security Area Advisors Group (SAAG) session was=20
>>dedicated to the discussion of hash function "breaks" and the=20
>>appropriate IETF response to this situation.
>>Eric Rescorla from gave a presentation on deploying a new hash=20
>>function.  The presentation is based on a paper that Eric=20
>>co-authored with Steve Bellovin. All of the IETF security protocols=20
>>that were analyzed required work in order to support transition to=20
>>new hash functions.  The paper is available at=20
>>http://www.cs.columbia.edu/~smb/papers/new-hash.pdf
>>Russ Housley gave a presentation on the Security Area response to=20
>>these hash function "breaks."  We should "walk, not run."  This is=20
>>not a problem yet, but as the attacks are improved it will become a=20
>>problem.  Russ shared his conclusions from the NIST Hash Workshop=20
>>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=20
>>two.  Within the Security Area, protocols with active WGs will be=20
>>analyzed within those WGs; others will be handled in SAAG.  The=20
>>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=20
>>functions, perhaps to a message authentication code.
>