RE: PKIX implications of SHA-1 collisions

["Santosh Chokhani" <chokhani@xxxxxxxxxxxx>]

I agree with Peter that we should first understand the attack well enough
(which I do not) before providing the solutions.

-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On
Behalf Of Peter Gutmann
Sent: Wednesday, February 16, 2005 11:27 PM
To: housley@xxxxxxxxxxxx; ietf-pkix@xxxxxxx
Subject: Re: PKIX implications of SHA-1 collisions



Russ Housley <housley@xxxxxxxxxxxx> writes:

>I think this can documented very quickly in a BCP.  It should just be a
>few pages.  I am willing to help write it.

I think it'd be better to wait a bit to get the full details.  Here's a
boilerplate summary I've been sending out to people who have mailed me about
this (personal opinion disclaimer, etc etc):

- It only affects the use of SHA-1 as a hash function, not as a PRF or HMAC,
  so the core of SSH, SSL/TLS, etc etc are unaffected.

- I've seen one report that it only affects the compression function and not
  the full hash function, which sounds plausible.  SHA-1 (and indeed all of
  the MD4-type UFN hashes) use a core compression function and then perform
  extra operations for the full hash function, so finding collisions in the
  full hash is somewhat more difficult than just the compression function.

- It takes 2^69 ops on average to find a second input value that produces
the
  same output as the first one (the ambiguous phrasing here is meant to
  indicate that probably what's meant is that the compression function
  produces the same output rather than the full SHA-1 hash producing the
same
  output, see above).  The second input value can't be chosen by the
attacker,
  so the chances of forging a signature on structured data like a
certificate
  or CMS/PGP message are fairly remote.

So while it's a very interesting result, it's more a hint to consider moving
to something else rather than time to hit the panic button.  RIPEMD-160
still looks fairly secure, my gut feeling is that its dual-path construction
is safer than the SHA-1 derived SHA-256 et al, but I suspect that in the
light of the current work on attacking UFN-based designs we'll be seeing a
pile of new non-UFN hash functions in the same way that differential
cryptanalysis spurred a burst of work on new ciphers.

Peter.