Re: Security Area Response to Hash Function "Breaks"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--24612531-1561-1133364987=:4168
Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1; FORMAT=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <[email protected]>

In the context of Digest-MD5, we're mostly concerned about pre-image=20
resistance. I further assume that the entropy of the underlying password=20
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=20
> size.  NIST made this recommendation before the flaws in SHA-1 were=20
> discovered.  SHA-1 is a 160-bit hash.  MD5 is a 128-bit hash.  Can you=20
> explain why the smaller hash value is acceptable in the SACRED protocol=
=20
> context beyond 2010?
>
> Russ
>
> At 09:56 AM 11/30/2005, Magnus Nystr=F6m wrote:
>
>> Please see below.
>>=20
>> In light of recent cryptanalytic results on hash functions, each IETF=20
>> working group is asked to provide an analysis of its use of hash functio=
ns.
>>=20
>> SACRED rely on DIGEST-MD5, but IMO SACRED does not become vulnerable to=
=20
>> attacks due to recent results on MD5. The reasons are that in Digest-MD5=
,=20
>> hashes are either done on nonces provided both by the client and the ser=
ver=20
>> or on the username and password selected by the client. Hence an attacke=
r=20
>> cannot perform a collision attack - in the former because the nonces are=
=20
>> not known in advance and in the latter case since it would be equivalent=
 to=20
>> finding the password, at which point he could impersonate the user anywa=
y.
>>=20
>> Comments, anyone?
>>=20
>> -- Magnus
>>=20
>> On Thu, 24 Nov 2005, Russ Housley wrote:
>>=20
>>> Below is a summary of the discussion that occurred at the SAAG session=
=20
>>> during IETF 64. When MD5 or SHA-1 is used to support digital signatures=
 or=20
>>> used by itself, recent cryptographic research findings indicate the nee=
d=20
>>> for a transition.  Therefore, I encourage all IETF WGs to follow the le=
ad=20
>>> of the Security Area in transition away from MD5 and SHA-1 toward SHA-2=
56.
>>> TCP-MD5 is one example where a transition is needed.  In this case, a=
=20
>>> 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 appropria=
te=20
>>> IETF response to this situation.
>>> Eric Rescorla from gave a presentation on deploying a new hash function=
=2E=20
>>> The presentation is based on a paper that Eric co-authored with Steve=
=20
>>> Bellovin. All of the IETF security protocols that were analyzed require=
d=20
>>> work in order to support transition to new hash functions.  The paper i=
s=20
>>> available at http://www.cs.columbia.edu/~smb/papers/new-hash.pdf
>>> Russ Housley gave a presentation on the Security Area response to these=
=20
>>> hash function "breaks."  We should "walk, not run."  This is not a prob=
lem=20
>>> yet, but as the attacks are improved it will become a problem.  Russ=20
>>> shared his conclusions from the NIST Hash Workshop held on October 31st=
=20
>>> 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.=
=20
>>> Within the Security Area, protocols with active WGs will be analyzed=20
>>> within those WGs; others will be handled in SAAG.  The following direct=
ive=20
>>> 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.
>>=20
>
>
--24612531-1561-1133364987=:4168--