It still sounds like Keyczar is the way to go among current available libraries, despite its now multiple discovered exploits (which have presumably been fixed by the time they were disclosed).
Regardless of what feature set and implementation is ready for primetime today, I have a question for security folks: Wouldn't it make sense for "the rest of us" (those of us who do not understand crypto beyond a basic comprehension the types and how to use them from a high level) just to pick the most popular crypto library (and backed by a major corporation that has a very strong vested interest in security that works)? Age seems to have merit, as well. We're using OpenSSL, plus Perl bindings, and GPG for our various crypto needs in our products, but if we were doing something fancy, beyond https and encrypting billing data with a public gpg key, what would be the safe choice at this point in time?
The problem with your second graf is that Nate isn't just talking about library implementation bugs. He's saying that the interfaces to some of these libraries are insecure. For instance, you're using OpenSSL; OpenSSL's crypto primitives do essentially nothing to protect you from a host of implementation failures, from failing to properly MAC your messages to leaking error information to checking parameters.
Keyczar and OpenSSL are not only not on the same playing field, they aren't playing the same sport. Keyczar is saying, "you want to do crypto, you're not a cryptographer, so we'll make all the hard decisions for you and give you a programmer-proof interface". OpenSSL is saying "here are the control rods, try not to blow the reactor up".
As for your first graf, I think it's a bit strange to take a post where a noted, respected expert on crypto is telling you not to use Keyczar, and extract from that the comment that Keyczar seems like the way to go. If Nate says not to use Keyczar, my advice is that picking it right now might be a professional embarassment in the coming year.
As for your first graf, I think it's a bit strange to take a post where a noted, respected expert on crypto is telling you not to use Keyczar, and extract from that the comment that Keyczar seems like the way to go. If Nate says not to use Keyczar, my advice is that picking it right now might be a professional embarassment in the coming year.
I read his comments as being "there is nothing good; here's why all of these things suck, but I grudgingly guess Keyczar works for some people". The only alternatives under discussion are cryptlib, which only has C bindings currently, and djb's new thing which uses brand new (well, four year old) ciphers that nobody other than djb really understands or knows to be secure. Given that Keyczar has some major corporate backing, and a reasonable level of community support, it seems a pretty solid choice...despite its imperfections. djb's thing might be an awesome choice...but we don't know and I'm definitely not qualified to figure it out.
Again, I'm just some guy, you know? I don't understand the nuances of security very well, but I read what I can and try to make some sense out of the kinds of answers security experts provide (which, for some reason, always seem to be qualified into being no-op statements; I guess because committing to recommending something means you can be proven wrong later when that recommendation proves insecure).
So, my reading comprehension I guess is as weak as my crypto knowledge, since I came away thinking, "Well, there's nothing good to use. But maybe Keyczar or cryptlib is better than what we're doing now; djb's might be awesome in the future. cryptlib has an annoying deployment aspect and would require me to write bindings that would probably be insecure, so Keyczar seems maybe the best of a bad lot."
I don't know of anyone who has a problem with Guttman's cryptlib. If I had to choose between NaCl and Keyczar right now, I'd recommend (after "not doing crypto") using NaCl.
I think that it's unlikely that you'll introduce serious crypto flaws by writing a binding to a high-level interface (the same is not true of binding to low-level interfaces like OpenSSL, where you could very easily weaken a construction).
cryptlib has many HLL bindings. If you're building something that's compatible with its Sleepycat license (GPL if you're OSS, pay if you're not), then just use it.
djb's little creation needs more cooking, that much is for certain. Brand new all but unreviewed ECDH, stream and hash functions. The hash isn't even in the SHA-2 competition. It doesn't matter who djb thinks he is, using this library in its current form is irresponsible.
Salsa20 is an ECRYPT eSTREAM Phase 4 cipher, tied with Rabbit for the #1 software stream cipher. eSTREAM is to stream ciphers what what the AES competition was to block ciphers. The eSTREAM committee included Bart Preneel, Vincent Rijmen, and Matt Robshaw. If the thing you're reacting to is that NaCl doesn't use AES, note that the peer review Salsa20 got was substantial.
Elliptic Curve Diffie-Hellman (ECDH) isn't "all but unreviewed". ECDH is a NIST standard. Curve25519 is just an implementation of ECDH over a set of parameters that admits to especially fast implementation.
The hash function in NaCl is SHA-512.
Poly1305 isn't a hash function. It's a polynomial MAC, similar to what's used in the NIST standard GCM. If that's what you were referring to as "the hash function that isn't even in the SHA-2 competition", note that none of the NIST authenticated encryption modes use (comparatively slow) generic hash function constructions like HMAC, and none of the MAC functions they do use (OMAC, CBC-MAC, GCM's poly eval) have been entered, like apples, into SHA-2's orange competition.
I don't know who you think Daniel J. Bernstein is, but the short answer is: extremely reputable cryptographic researcher.
The sad thing is, your core argument --- that it would be "safer" to use NaCl using the NIST curves and AES --- is valid, and would have been informative if you hadn't chosen to phrase it in such a dismissive way. As it stands, I'm left thinking you don't know what you're talking about and just stumbled on this critique, particularly as your professional background contains basically no crypto or security.
Either way, you are almost certainly better off using NaCl with DJB's bespoke algorithms than you are trying to patch AES, HMAC-256, and RSA together using OpenSSL. We break actual peer-reviewed cryptographic algorithms in the field during penetration tests basically never. We break homebrew AES and RSA constructions about once a month.
What I was trying to get across in my post is that there is no easy answer currently. cryptlib may be best if you are ok with the license. Keyczar is a good start, but it needs more time to be fully-baked. GPGME is a bit clunky and C-only. I have no clear recommendation, and that sucks.
Hopefully people will rally around these. Cryptographers to review these libraries and NaCl. Developers to add the HLL bindings. Note that NaCl has a high-level API, so the HLL binding may just be SWIG + wrapper to convert length-counted byte buffers into the appropriate sequence type.
I think "irresponsible" is much too strong. As tptacek says, he is getting a lot of review and his constructions are not excessively risky. I just think they need more time to be reviewed and the early findings seem to be that they are pretty good.
Regardless of what feature set and implementation is ready for primetime today, I have a question for security folks: Wouldn't it make sense for "the rest of us" (those of us who do not understand crypto beyond a basic comprehension the types and how to use them from a high level) just to pick the most popular crypto library (and backed by a major corporation that has a very strong vested interest in security that works)? Age seems to have merit, as well. We're using OpenSSL, plus Perl bindings, and GPG for our various crypto needs in our products, but if we were doing something fancy, beyond https and encrypting billing data with a public gpg key, what would be the safe choice at this point in time?