"Whyte, William" <[EMAIL PROTECTED]> writes: >> > > > This is incorrect. The simple form of the attack >> > > > is exactly as described above - implementations >> > > > ignore extraneous data after the hash. This >> > > > extraneous data is _not_ part of the ASN.1 data. >> >> James A. Donald wrote: >> > > But it is only extraneous because ASN.1 *says* it is >> > > extraneous. > > No. It's not the ASN.1 that says it's extraneous, it's the > PKCS#1 standard. The problem is that the PKCS#1 standard > didn't require that the implementation check for the > correct number of ff bytes that precede the BER-encoded > hash. The attack would still be possible if the hash > wasn't preceded by the BER-encoded header.
That's not true -- PKCS#1 implicitly require that check. PKCS#1 says the verification algorithm should generating a new signature and then compare them. See RFC 3447 section 8.2.2. That solves the problem. Again, there is no problem in ASN.1 or PKCS#1 that is being exploited here, only an implementation flaw, even if it is an interesting one. After reading http://www.rsasecurity.com/rsalabs/node.asp?id=2020 it occurred to me that section 4.2 of it describes a somewhat related problem, where the hash OID is modified instead. That attack require changes in specifications and implementations, to have the implementation support the new hash OID. But it suggests a potential new problem too: if implementation don't verify that the parsed hash OID length is correct. E.g., an implementation that uses memcmp (parsed-hash-oid, sha1-hash-oid, MIN (length (parsed-hash-oid), length (sha1-hash-oid))) to recognize the hash algorithm used in the ASN.1 structure, it may also be vulnerable: the parsed-hash-oid may contain "garbage", that can be used to "forge" signatures against broken implementations, similar to the two attacks discussed so far. I don't know of any implementations that do this, though. /Simon --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]