Re: High-priority library replacements?

[Gregor Pintar <grpintar@gmail.com>]

2013/4/26, idunham@lavabit.com <idunham@lavabit.com>:
> I hate to be the one who says this, but...
> Why another crypto library?
> There are at least 6 I can think of off the top of my head
> (openssl crypto, gcrypt, nettle, tomcrypt, gpg, openbgp)
> and I know that's not even half of them.
> tomcrypt is already good (as Rich mentioned), so code quality isn't
> a reason.
Most of them are realy bad (support only few ciphers, ugly API,
inflexible, license).
tomcrypt is good, but it has some global states (ltc_cipher_descriptor, ...)
and I want even more flexible library (variable rounds, no global state).
I would like API that allows replacing ciphers very easy.
For example: allways use kripto_stream_encrypt(),
if you use any block cipher in any mode or stream cipher directly.
Also my hash API supports variable length output (great for sponge
constructions).

> While writing your own "xyz" may be a good learning experience and fun
> and so on, a crypto library faces some restrictions:
> -You will need to fix bugs promptly until you hand over maintainership.
> (Otherwise, you become responsible when there's a vulnerability that
> stays unfixed.)
Not really a problem for me.
BTW, latest official stable tomcrypt release was released in 2007.

> -You have to finish it.
> Consider the case of gcrypt, which is a GNU project with multiple
> contributors, but still doesn't implement enough to make LDAP over SSL
> work in all cases (I don't know the exact issue, but it's a standing bug
> in Debian.)
I am trying to do it very extensible.

> And you have to write a good API.  When someone else has a library with
> that, you may be better off using it.
That is the hardest. API better than tomcrypts is my goal.
I also plan stable ABI.

> What Rich asked about was an SSL lib based on an existing crypto lib,
> namely tomcrypt. And that is likely to be a quicker path to results.
tomcrypt is definitely quicker path.

>> I think best way is not to trust any certificate authority.
>> Maybe some certificate p2p protocol could be done?
>
> Not really an option for regular SSL, I'm afraid.
> (just due to the standards, and the need for getting it going...)
> But something along the lines of OpenBGP (I think that's the name; it's
> a BSD-licensed PGP library) would be one place to start if you wanted
> that.
> It would be interesting if the library transparently handles both SSL
> and something along those lines, so someone gets the certificate p2p
> stuff for free by using the library.
I know, it was more like an long-term idea.