Leandro Meiners <lmein...@gmail.com> quotes: >"For example, by specifying an HMACOutputLength of 1, only one bit of the >signature is verified. This can allow an attacker to forge an XML signature >that will be accepted as valid."
This excessive generality is a serious problem in way too many crypto specs, and implementations of security protocols. For example PKCS #11 allows you to leak keys out of cryptographic hardware by specifying the use of a 1-bit key derivation function, allowing you to guess an entire key one bit at a time (fortunately few, if any, implementations actually support this). In the PKI world, virtually no spec requires sensible limits on anything (some years ago I brought a CA to a halt by specifying a huge salt and large iteration count for the challenge-response protocol they used to authenticate certificate issues. Then I repeated it to make sure it wasn't just a coincidence the first time :-). PGP Desktop 9 uses as its default an iteration count of four million (!!) for its password hashing, which looks like a DoS to anything that does sanity-checking of input. Netscape (and obviously this test was done some years ago) will happily accept a certificate with a 1MB MPEG of a cat in the X.500 DN, but then become what could mildly be described as "unresponsive" once it's stored it in its cert.database. The SSH oracle attack of a few months ago was helped by the fact that the length field wasn't constrained to sensible values. This list goes on and on, it's scary just how vulnerable a lot of security software is to anything that can drop a slightly unexpected value into a data field. Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com