Date: Fri, 26 Apr 2013 10:11:32 +0200 From: Gregor Pintar <grpintar@...il.com> To: musl@...ts.openwall.com Subject: Re: High-priority library replacements? 2013/4/26, idunham@...abit.com <idunham@...abit.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.
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.