Re: Efficiency of libtasn1?

[Nikos Mavrogiannopoulos]

On Thu, Mar 10, 2016 at 1:21 PM, Rick van Rein <address@hidden> wrote:
> Hi Tim,
> Thanks for your addition!
>> If in doubt, as Nikos said, benchmark your process.
>> What I did for this quick shot is
>> valgrind --tool=callgrind gnutls-cli www.amazon.de >/dev/null
>> valgrind --tool=callgrind openssl s_client -connect www.amazon.de:443
>> and displaying the results with kcachegrind.
> I am not aiming for TLS, but for much simpler things, such as LDAP,
> possibly for internal use (keyserver, contact server).  I am aware that
> there are only large-scale solutions for LDAP and I would like to come
> to something much more modest ("LilyDAP" might be a name) and perhaps
> pluggable, akin to web servers.
>
> On the development side I was looking for an embedded style for the low
> end ("run your identity provider on
> yet-another-simple-device-of-the-day), desiring the smallest possible
> code and storage; I also believe that the same techniques can greatly
> leverage large-scale roll-out on the high end.
>
> I have been twisting my head around the question if it would be possible
> to modify just the internals of libtasn1, while retaining the API, but I
> failed; I kept coming around to "this requires some static form of
> walk-through description".

Could that be handled with some kind of code generator?


>  I started prototyping tha idea and created a
> "Quick DER" parser that is much closer to these wishes.  (I also
> discussed the need for an open source toolkit with this style of
> programming with crypto-domain peers, who agreed it would be very useful
> to have.)

Not sure I have completely understood the API; What I understand is
that with this API one should manually handle nested structures (e.g.,
sequences inside sequences, etc). However, complexity in typical ASN.1
protocols comes in the complex, nested, and deeply nested structures,
choices etc. The worst offender there is PKCS #12 which is nearly
impossible to hand craft a parser for it. That's where libtasn1
changed the game and allowed for relatively easy parsing of these
structures (despite its numerous limitations and issues).

On the other hand the quickder parser will be able to handle quite a
large number of nesting without requiring much memory and the code
would be relatively simple for well-designed protocols (e.g.,
kerberos).

> I didn't report it here because I thought it might not be considered
> pleasant to hear that someone went another way.  But if you are
> interested, you are of course welcome to take a look at this totally
> different approach,
> http://github.com/vanrein/quick-der

I think it is certainly a good thing to have more than one options.
Libtasn1's internals are quite complex, and difficult to follow and I
also prefer something simpler (and even further something I wouldn't
have to maintain myself :) The advantage of libtasn1 though is that it
has been fuzzed quite a lot due to gnutls and is known to work
reliably for the use cases it can handle.

regards,
Nikos