James A. Donald wrote: > -- > Greg Rose wrote: >> At 19:02 +1000 2006/09/14, James A. Donald wrote: >>> Suppose the padding was simply >>> >>> 010101010101010 ... 10101010101010000 hash >>> >>> with all leading zeros in the hash omitted, and four >>> zero bits showing where the actual hash begins. >>> >>> Then the error would never have been possible. > > James A. Donald: >> I beg to differ. A programmer who didn't understand >> the significance of crypto primitives would (as many >> did) just search for the end of the padding to locate >> the beginning of the hash, and check that the next set >> of bytes were identical to the hash, then return >> "true". So > > The hash is known size, and occurs in known position. > He does not search the padding for location, but > examines it for correct format. > >> >> 01010101 ... 10101010101010000 hash crappetycrap >> >> would still be considered valid. There's a lot of code >> out there that ignored the fact that after the FFs was >> specific ASN.1 stuff, and just treated it as a defined >> part of the padding. > > And that code is correct, and does not have the problem > that we discuss. Paying attention to ASN.1 stuff is > what is causing this problem.
No, it is incorrect and does have the problem we discuss. The fact that it ignores the crap that's after the hash makes it vulnerable. > Code is going wrong because ASN.1 can contain > complicated malicious information to cause code to go > wrong. If we do not have that information, or simply > ignore it, no problem. 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. The more complex form of the attack does actually use the ASN.1, in the form of the parameters field. However, I'm not sure why you'd single out ASN.1 as the cause of this problem: once the designers of the protocol decided you needed parameters, the door was opened to the attack. Implementations can incorrectly ignore the extraneous parameters no matter how you encode them. Not that I'm a fan of ASN.1, but if we're going to blame it for problems, we should do so only when it is actually to blame. The fault in this case is a combination of overly flexible protocol design and implementation flaws. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
