[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Cfrg] Re: [saag] Bad day at the hash function factory



On Thu, Aug 19, 2004 at 08:59:27PM -0400, james hughes wrote:

> One comment and two discussion points.
> 
> Can we withdraw the MD5 RFC as obsolete?

Seems odd to do so, given that OpenPGP, TLS, PKIX and tons of other IETF
projects continue to use (or at least support the use of) MD5 in some context
or another.

> On Aug 19, 2004, at 12:23 PM, David A. McGrew wrote:
> >>WHAT'S SAFE?
> >>First, anything that's already been signed is definitely safe.  If you
> >>stop using MD5 today, nothing you signed already puts you at risk.
> 
> I sign a document (in the clear) which says "... pay me $100.00 ... " 
> and now I can create a document that to  "... pay me $10,000 ... " with 
> a collision. Just because the original is old, why are old these 
> documents safe?

Because doing so would require a second preimage, which is a different (and
presumably harder) attack than finding a collision with free choice of both X
and X'.

> 
> >>It's believed that HMAC is secure against this attack (according to 
> >>Hugo
> >>Krawczyk, the designer) so the modern MAC functions should all be
> >>secure.
> 
> While I believe this may be true, I believe that the proof that HMAC is 
> secure requires a collision resistant hash function. If this is the 
> case, then we no longer have a proof that HMAC is secure.  The SAAG 
> should understand this with open eyes.

Huh? The HMAC proof is still perfectly valid. The question is whether MD5 meets
the requirements of the proof, ie, is collision resistant when the IV is secret
and unknown. AFAIK, the current attacks are all based on a fixed known IV, and
until that is otherwise HMAC with MD5 should be secure. MACs are also usually
short-term, so an attack on (say) HMAC with MD5 that someone finds next year
will not affect TLS sessions done today.

-Jack

_______________________________________________
Cfrg mailing list
Cfrg at ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg