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 [email protected]
