Earlier this year, I posted that Bruce Schneier and I were writing an Internet Draft called "Attacks on Cryptographic Hashes in Internet Protocols". After a few rounds of improvements based on suggestions from the IETF and cryptography communities, it is now an Informational RFC: RFC 4270. (In IETFspeak, an Informational RFC is one that doesn't specify a standard; in this case, it reviews the current state of affairs of an important part of the Internet.)
One of the interesting aspects of this RFC is that it may be the only one where the two authors disagree about something as fundamental as "what to do next". While the document has been moldering in the RFC Editor's queue, a lot of new work has been done on hashes. NIST held a workshop a month ago, and the presentations are available for those of us who could not attend. The sense of the room was that people should consider moving to SHA-256 when practical, but determining when it is practical is far from clear.
For example, it would be silly to start issuing certificates using SHA-256 because virtually none of the systems that rely on certificates know how to validate with that algorithm. This introduces a massive chicken-and-egg problem: CAs won't start issuing certs until people can use them, and software vendors will not upgrade until customers demand it so they can validate certificates. The skeptical part of me guesses that we won't see widespread deployment of SHA-256 in certificates for at least five years.
This is not to say that no one is doing anything about it. IETF security stalwarts Steve Bellovin and Eric Rescorla presented a very good paper on deciding when and how to deploy new hash functions. Following up on that, I have started a new Internet Draft called Use of Hash Algorithms in IKE and IPsec. Part of the reason I wrote that is based on requests from my members in VPNC, but another part was to get the ball rolling in the IETF so that folks in other security areas write up the kind of material for their own protocols. Now, the groups that work on SSL/TLS, PKIX, S/MIME, PGP, Kerberos, SASL, and so on, need to start their documents as well, so that the rest of the world can see what needs to be done to deal with the new problems.
Posted by lookit at December 1, 2005 08:08 PM