MD5 considered harmful today, SHA-1 considered harmful tomorrow

[Weger, B.M.M. de]

Hi Peter,

> I have a general outline of a timeline for adoption of new 
> crypto mechanisms
> (e.g. OAEP, PSS, that sort of thing, and not specifically 
> algorithms) in my
> Crypto Gardening Guide and Planting Tips,
> http://www.cs.auckland.ac.nz/~pgut001/pubs/crypto_guide.txt, 
> see "Question J"

I had algorithms in mind, as the 'hash crisis' is about algorithms.
For algorithms the situation might be simpler than for protocols.

It is conceivable that one of these days some clever person comes
up with, say, a practical chosen-prefix collision attack on SHA-1,
enabling something similar as we did with MD5. It is also conceivable 
that some clever person completely breaks Rijndael, or RSA.
Do software vendors (such as browser vendors) and service providers 
(such as CAs) have disaster recovery plans for such a situation? 
Or are these simply 'accepted risks' that nobody worries about? 
In my view it would be prudent to move SHA-1 out of the no-worry
category.

One level up, and maybe an example of a general lesson James was
asking for: good practice to avoid availability problems is to
add redundancy. In hash functions the security in many applications
now seems to be completely based on SHA-1, a not-yet-broken but
known-to-be-weak algorithm. How can we avoid such situations?
(I am thinking long term here). When in 2012 the winner of the
NIST SHA-3 competition will be known, and everybody will start
using it (so that according to Peter's estimates, by 2018 half
of the implementations actually uses it), do we then have enough
redundancy? I was not around when Rijndael was chosen as the AES 
winner. Have there been discussions then about the number of winning 
algorithms? Why only one, and not three winners, say, with a 
sufficiently different design, that everybody then will implement? 
Can / should NIST do so with SHA-3? Is implementing three new hash
functions at the same time much more complicated than implementing
one?

Grtz,
Benne de Weger

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com