-- 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. James A. Donald wrote: > > But it is only extraneous because ASN.1 *says* it is > > extraneous. > > > > 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! Ben Laurie wrote: > If you ignore the ASN.1 stuff then you won't know what > hash to calculate. If true, irrelevant. If true, it would merely imply that they should not have used ASN.1 to represent the hash type. But in fact it is not true. I suspect a lot of implementations decide the hash type by looking for particular byte values at particular fixed locations, rather than by deciphering the data as ASN.1. To repeat my argument: A program can only correctly handle a small number of fixed data layouts, but ASN.1 can express an infinite variety of layouts, giving great scope for malicious data. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG bUm91GJmI9zp9B7QNyHcQVSy/PJPz6xQb/PIepFe 47yymkER8iV/Dv/2S5EmJ4XMufQI8aDE8j3ZF80nl --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]