Re: High-priority library replacements?

[idunham@lavabit.com]

On Thu, Apr 25, 2013 at 08:43:25AM +0200, Gregor Pintar wrote:
> Hello.
> 
> 2013/4/25, Rich Felker <dalias@aerifal.cx>:
> > 2. SSL. The modern internet basically requires using SSL everywhere.
> > We should be aiming/expecting to transition to a world where even
> > non-login-based sites are 100% https; the threats of malicious http
> > injection attacks from rogue or advertising-based access points has
> > gotten too great. Unfortunately, all of the existing SSL
> > implementations are bloated, buggy, and fail even the most basic
> > robustness requirements. A good solution would be based on tomcrypt
> > and would expose a minimal, simple API suited for event-loop-based or
> > threaded use. It may also be useful to have an optional wrapper layer
> > to expose an API that mimics openssl or gnutls. It should also be able
> > to keep up with the changing demands of how to determine which
> > certificate authorities are to be trusted.

> I am working on cryptographic library. It's far from being finished.
> I would be very glad, if someone could look at it.
> Currently I have problems with API design so help would be welcome.
> It isn't in git yet.
> You can get it here:
> https://dl.dropboxusercontent.com/u/83450675/kripto/kripto.tar.gz
> I have plans for SSL library on top of it, but it could take years.

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.
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.)
-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.)

And you have to write a good API.  When someone else has a library with
that, you may be better off using it.
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.

> 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.

> > All of these libraries should:
> >
> > - Avoid namespace pollution. Only external symbols should be the
> >   public API and internal-use stuff prefixed with an ugly prefix
> >   that's extremely unlikely to clash with anything.
> All external symbols have "kripto_" prefix.
> 
> > - Avoid unnecessary allocation. Use caller-provided objects where
> >   possible or provide both options.
> I am trying to do least malloc()s possible.
> 
> > - Have absolutely zero global state.
> There is no global state and there won't be any.

Sounding good, and looking good from what I saw. (Although I tend to
dislike "magic number tables", but that's mainly personal taste...
Also, don't consider me an authority on C or programming. I know some, 
but far too little.)

Thanks,
Isaac Dunham