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

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.


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to