On 9/14/06, James A. Donald <[EMAIL PROTECTED]> wrote:
It seems to me that the evil here is ASN.1, or perhaps standards that
use ASN.1 carelessly and badly.

It is difficult to write code that conforms to ASN.1, easy to get it
wrong, and difficult to say what in fact constitutes conforming to ASN.1
or at least difficult to say what in fact constitutes conforming to
standard written in ASN.1

ASN.1 does the same job as XML, but whereas XML is painfully verbose and
redundant, ASN.1 is crypticly concise.

People do not seem to get XML wrong all that often, while they endlessly
get ASN.1 wrong, and endlessly disagree over what constitutes being right.

This problem is just as likely or more likely if we were using XML to
encode the hash inside the RSA-encrypted blob (signature). The
equivalents would be:

Appended garbage:
 <signed-hash>Valid-looking-hash</signed-hash>Garbage here
 <signed-hash>Valid-looking-hash</signed-hash>[null byte]Garbage here

Interior garbage:
 <signed-hash legal-but-unparsed-attribute="Garbage

or similar attacks. The problem is not XML or ASN.1: the problem is
that it's very demanding and tricky to write parsers that are
invulnerable to all the different kinds of malicious attack that are
out there.

If anything, I think XML is more vulnerable to such attacks because
its less-structured format makes it harder to write very strict
parsers. The actual way to design a system that was less vulnerable to
this attack would have been to use a much simpler data structure:
e.g., one could have said that the hashing algorithm must already be
known, so the size of the hash is known to be n bytes, and that the
data block should be a byte of value 0, followed by bytes of value FF,
with the last n bytes equal to the hash. Then it would have been a
no-brainer for anyone to write a precisely accurate parser and
validator, and we'd be less vulnerable to such oversights.

- Tim

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

Reply via email to