[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130426015114.GP20323@brightrain.aerifal.cx>
Date: Thu, 25 Apr 2013 21:51:14 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: High-priority library replacements?
On Thu, Apr 25, 2013 at 05:55:45PM -0700, idunham@...abit.com wrote:
> > 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.
Yes. Crypto is hard to get right and when there's an implementation
with high-quality public domain code, I think you'd need a really
strong justification for using a new crypto implementation in an SSL
library.
> > 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.
Yes, I don't really know what the future directions will be, I just
think a library should be prepared to adapt to changing needs for how
we determine trust.
> > > - 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.)
If you dislike magic number tables, you can always include a script in
the build process to generate them. Using tens or hundreds of kb per
process and tons of startup time however is not an acceptable solution
to "I dislike magic number tables". Like them or not, magic number
tables are the only non-bloated solution.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
