James A. Donald wrote:
James A. Donald wrote:
>> 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.

Ben Laurie wrote:
> 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.

But it is only extraneous because ASN.1 *says* it is

If you ignore the ASN.1 stuff, treat it as just
arbitrary padding, you will not get this problem.  You
will look at the rightmost part of the data, the low
order part of the data, for the hash, and lo, the hash
will be wrong!
This is a question I would not mind having answered; while the exponent 3 attack works when there are low bits to 'modify', there has been talk of an attack where the ASN.1 is correctly right justified (hash is the least significant bytes), but incorrect ASN.1 encoding is used to add 'arbitrary' bytes before the hash. So in this case some of the most significant bytes are fixed, the least significant bytes are fixed, but some in the middle can be modified. Does the exponent 3 attack work in this case? My personal feel is that his would be much harder, but is such an attack infeasible?

This issue about ASN.1 parameters being an evil concept goes away if the attack can only work when the least significant bytes need to be modifiable.


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

Reply via email to