Exponent 3 damage spreads...

Tim Dierks tim at dierks.org
Thu Sep 14 11:12:56 EDT 2006


On 9/14/06, James A. Donald <jamesd at echeque.com> 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
Or
  <signed-hash>Valid-looking-hash</signed-hash>[null byte]Garbage here

Interior garbage:
  <signed-hash legal-but-unparsed-attribute="Garbage
here">Valid-looking-hash</signed-hash>

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 majordomo at metzdowd.com



More information about the cryptography mailing list