Re: PKIX implications of SHA-1 collisions

["todd glassey" <todd.glassey@xxxxxxxxxxxxxxxx>]

It also may be true that in the risk models where SHA-1 is used it could be
fine still. This may be more as important as understanding the attack.

Todd

----- Original Message ----- 
From: "Santosh Chokhani" <chokhani@xxxxxxxxxxxx>
To: <ietf-pkix@xxxxxxx>
Sent: Thursday, February 17, 2005 7:21 AM
Subject: RE: PKIX implications of SHA-1 collisions


>
> 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.
>
>
>