Simon Josefsson <[EMAIL PROTECTED]> writes: >Deploying a hash widely isn't done easily, though. GnuTLS only support MD2, >MD5, SHA-1 and RIPEMD (of which MD2/MD5 are by default not used to verify >signatures).
Right, but it's been pure luck that that particular implementation (and most likely a number of others) happen to have implemented only a small number of hash algorithms that allow only absent or NULL parameters. Anything out there that implements a wider range of algorithms, including any that allow parameters, is most likely toast. What's more scary is that if anyone introduces a parameterised hash (it's quite possible that this has already happened in some fields, and with the current interest in randomised hashes it's only a matter of time before we see these anyway), then changing a simple AlgoID definition in one part of the code is going to suddently break signatures 23 code modules away in a different directory. Will whoever's responsible for maintaining the hash AlgoID table in some far-removed code module in several years' time know that any change they make could cause a security breach via a non-obvious mechanism in a far-distant piece of code? This is just going to keep coming back and biting us again and again unless we default to deny-all. The e=3 issue is like the old war movies where someone steps on a mine and hears the click, but isn't quite sure yet how long it'll be before they spread themselves decoratively around the countryside. We've heard the click, it's time to get out of the minefield. Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]