--
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]
