[Monotone-devel] Fw: [TLS] Time for ciphersuites with new hashes?

[Richard Levitte - VMS Whacker]

In light of the recent report on SHA-1 vulnerability, I want to share
the words of Peter Gutmann, a well known cryptographer (and more) for
whom I have enormous respect.

Cheers,
Richard

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 52
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: [TLS] Time for ciphersuites with new hashes?
>
>
>
>
> Date: 
>
> Thu, 17 Feb 2005 16:51:12 +1300
>
>
>
>
> Nelson B Bolyard <address@hidden> writes:
>
> >In light of the news that SHA1 has been "broken"
> >http://www.schneier.com/blog/archives/2005/02/sha1_broken.html (collisions
> >can be found with much less work than predicted), is it time for us to be
> >defining new ciphersuites that employ SHA256, SHA384 and/or SHA512?
>
> Just to put this into perspective:
>
> - 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 hash functions) 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 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.
>
> _______________________________________________
> TLS mailing list
> address@hidden
> https://www1.ietf.org/mailman/listinfo/tls
>
>
> --- End Message ---