[Cryptography] DIME // Pending Questions // Seeking Your Input
phill at hallambaker.com
Sun Mar 1 15:07:44 EST 2015
On Sun, Mar 1, 2015 at 10:28 AM, Jerry Leichter <leichter at lrw.com> wrote:
> On Mar 1, 2015, at 8:47 AM, Phillip Hallam-Baker <phill at hallambaker.com>
> ...In particular, a decoder can verify the syntactic correctness of each
> token in the stream in a single pass using only the data previously read.
> Checking correctness of an ASN.1 file is a real horrorshow because an inner
> length encoding can be inconsistent with either an outer or an inner one.
> Not to disagree that this is a good feature, but ... having written
> (actually, fixed) a parser for an encoding (not ASN.1, which has its own
> special complexities) that used a nested TLV (Type/Length/Value encoding),
> I'd say it's not particularly hard to get the bounds checking right. But
> you have to design for it from the beginning and follow the design
Which in practice means rewrite every damn library yourself if you want to
Yes, I can write that code but I don't and can't trust anyone else to.
Still, I'll agree that people get this on-its-face trivial bit of coding
> wrong all the time. A parser generator is really the way to go: Get it
> right once and for all.
Which is what I use for everything: JSON, XML or ASN.1. I have one for
RFC822 headers as well. I use a tool whether I am going to use C or C#.
Problem is when you encounter other people's stuff.
XML DER is the pits because the length values are themselves of variable
The trick I have found with XML DER is to actually write out the structures
in reverse. This has the effect that the length of each structure can be
finalized at the time you emit the data and you can do everything in one
pass. Or if you want to pre-allocate the data in one chunk and not worry
about having to extend the output buffer, make two passes.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cryptography