On Thu, Aug 27, 2009 at 11:30:08AM +1200, Peter Gutmann wrote: > > Thor Lancelot Simon <t...@rek.tjls.com> writes: > > >the exercise of recovering from new horrible problems with SHA1 would be > >vastly simpler, easier, and far quicker > > What new horrible problems in SHA1 (as it's used in SSL/TLS)? What old > horrible problems, for that matter? The only place I can think of offhand > where it's used in a manner where it might be vulnerable is for DSA sigs, and > how many of those have you seen in the wild?
I think we're largely talking past one another. As regards "new horrible problems" I meant simply that if there _are_ "new horrible problems_ such that we need to switch away from SHA1 in the TLS PRF, the design mistakes made in TLS 1.1 will make it much harder. As I read Ben's comments, they were _advocating_ those kinds of design mistakes, advocating hard-wiring particular algorithms or their parameter sizes into protocols, because -- as I understood him -- both replacing and algorithm and replacing a whole protocol are just "software upgrades" and all software upgrades are alike. Well, I don't think it's true that all software upgrades are alike in the relevant way. In fact, it is radically harder to replace an entire protocol, even with a related one, than to drop a new algorithm into an existing, properly-designed protocol. It may be no different for _users_, but the difference for _implementers_ is vast, and that greatly delays the availability of the relevant software upgrade to users, which is not a good thing. I think the current TLS 1.2 debacle is about the best evidence of this one could ask for. If TLS 1.{0,1} had been designed to make the hash functions pluggagle everywhere they're used, then users would have new software which didn't rely on SHA1 (even in a way we currently think is still safe) available now, rather than having to wait quite a bit longer before the possibility of upgrading even arose. Thor --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com