[cryptography] preventing protocol failings

Nico Williams nico at cryptonector.com
Wed Jul 6 14:19:14 EDT 2011

On Wed, Jul 6, 2011 at 1:25 AM, Peter Gutmann <pgut001 at cs.auckland.ac.nz> wrote:
> Nico Williams <nico at cryptonector.com> writes:
>>On Wed, Jul 6, 2011 at 12:06 AM, Peter Gutmann
>><pgut001 at cs.auckland.ac.nz> wrote:
>>> (The ASN.1 filter I mentioned earlier is a stripped-down version of dumpasn1.
>>> Remember that dataset of 400K broken certs that NISCC generated a few years
>>> ago and that broke quite a number of ASN.1-using apps (and filesystems when
>>> you untarred it :-)?  It processed all of those without any problems).

To be fair, when I wrote that "you have to know the schema and message
type in order to do a good job of parsing the message", what I had in
mind was an actual application, not a forensic/debug tool like
dumpasn1 (I also used the weasel modifier "good" for "job" because I
knew that one could apply heuristics to decode implicitly tagged
BER/DER/CER, but still, it's only a weasel word).

An actual application implementation just needs to know the ASN.1
types of the message being decoded, and this is equally true of PER as
of BER.  That dumpasn1 would not work at all with PER-encoded messages
doesn't bother me very much, as it wouldn't be hard to know the
relevant ASN.1 types from context and then use a properly built
decoder instead.  That said, I'd kinda like a tool that can interpret
ASN.1 types on the fly and decode into a human readable (think
wireshark) form.  Heimdal's ASN.1 toolchain includes a templating
feature that need to understand -- it might be helpful here.


More information about the cryptography mailing list