Exponent 3 damage spreads...

[Peter Gutmann]

"Leichter, Jerry" <leichter_jerrold at emc.com> writes:
>| I don't think it's a problem, you just take the ASN.1 DigestInfo
>| value, since the trailing garbage isn't part of the DigestInfo, you
>| ignore it.  Specifically, the ASN.1 object is entirely self-contained,
>| so you can tell exactly where it ends and what it contains.  Anything
>| outside it is beyond the scope of this specification :-).
>
>This is a rather peculiar interpretation of the spec.  If I look at a C
>specification and it tells me that an integer is a string of digits, when I
>write a C compiler, am I permitted to say that "123@#&%" can be parsed as an
>"entirely contained" integer, with the "@#&%" "beyond the scope of the
>specification"?

No, because the compiler doesn't use a TLV encoding as ASN.1 does.  Take
something like an MPEG, JPEG, MP3, or some other piece of data that uses a TLV
encoding with a clearly defined (by the data) end.  Cat some extra garbage
onto the end of it, and try and view/play it.  If it's a proper TLV encoding
(rather than a TV encoding, i.e. no explicit length info included) then the
decoder/player will ignore the extra garbage at the end*.  That's the whole
point of TLV encodings, you know a priori when to stop, and stop exactly at
that point.

Peter.

* There are some that might keep reading in the hope that something else crops
  up, I don't know, but the ones I've looked at don't care if there's extra
  junk at the end.  This goes back at least as far as CP/M, where you could
  have extra ^Z's and other junk at the end of files that apps had to avoid
  ploughing into.
  

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com