[Cryptography] [FORGED] Re: Is ASN.1 still the thing?
cryptography at lakedaemon.net
Tue Nov 14 10:49:41 EST 2017
On Tue, Nov 14, 2017 at 04:42:37AM +0000, Peter Gutmann wrote:
> Jason Cooper <cryptography at lakedaemon.net> writes:
> >Above and beyond the complexities of parsing it, there's also the difficulty
> >of parsing it on embedded systems. From my experience, it's extraordinarily
> >difficult to parse as a stream.
> What experience did you have that makes you say that? My code runs on a ton
> of embedded stuff and there's no problems with parsing it, as a stream or
>From the perspective of attempting to decode an x509 cert as it streams
in. We found one attempt at decoding while streaming:
> You can't encode the length of the structure before you know all the
> lengths of its components, and in the streaming mode the components
> lengths may not be easily available.
> In the DER encoding, the length of the message being encoded needs to be
> known in advance. Therefore, der_encode() won't be able to generate the
> proper output.
> However, in the more broad BER encoding, there's a possibility to encode
> a so-called “indefinite length” component size. Unlike the
> Tag-Length-Value component encoding when its length is available, the
> “indefinite length” in BER acts as an opening brace in a programming
> language: you have to terminate the encoding after all the components of
> the structure are encoded. The termination is done using two consecutive
> zero-data octets.
> Essentially what is it all about is that you encode the components of a
> particular ASN.1 structure yourself, using DER encoding, but wrap it all
> up with a framing of “indefinite length”.
So, in blunt terms, a "hack".
Thanks to Howard, we now have a second example, liblber which has a long
history, plenty of use, and is open source. So we'll see how that
But the fact is, DER was never intended for stream parsing/encoding.
More information about the cryptography