[Cryptography] [FORGED] Re: Is ASN.1 still the thing?

Jason Cooper cryptography at lakedaemon.net
Wed Nov 15 09:16:07 EST 2017


Hi Howard,

On Tue, Nov 14, 2017 at 08:16:19PM +0000, Howard Chu wrote:
> Jason Cooper wrote:
> >On Tue, Nov 14, 2017 at 04:42:37AM +0000, Peter Gutmann wrote:
> >>Jason Cooper <cryptography at lakedaemon.net> writes:
> >>
> >>>[ASN.1]
> >>>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
> >>otherwise.
> >
> > From the perspective of attempting to decode an x509 cert as it streams
> >in.  We found one attempt at decoding while streaming:
> >
> >   http://lionet.info/asn1c/blog/2010/09/22/question-how-to-use-streaming/
> >
> >Specifically:
> >
> >>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".
> 
> This sounds like you want to concurrently decode and re-encode,
> which is a slightly more unusual requirement. But yes, while it's
> possible to do a streaming decode, you can't really do a streaming
> encode.

No, that's the similar problem we encountered on the net.  We're happy
with serial decode and, asynchronously, serial encode.

thx,

Jason.


More information about the cryptography mailing list