[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Efficiency of libtasn1?
From: |
Rick van Rein |
Subject: |
Re: Efficiency of libtasn1? |
Date: |
Thu, 10 Mar 2016 13:21:24 +0100 |
User-agent: |
Postbox 3.0.11 (Macintosh/20140602) |
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". 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.)
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
This is pretty much what I had in mind when I was looking for an ASN.1 /
DER parser -- very tiny, very efficient and it can even work without
allocating memory anywhere but on the stack. Of course I am widely open
to feedback and critism of any kind (though this list may not be the
right forum for it).
Thanks,
-Rick