--
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.
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.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
8Jickn3nr3AE+2RW3jUC7DaHw6yD1gLpSTISH0F6
4Bjf3VmASP+HQ4q0CYdRKgWFZxd/QnFOiartuob5Q
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
