It’s nearly impossible to prevent side channel attacks when your crypto is implemented in a high-level language.
AMEN!
I've been trying to make this point to people for years, but it has been hard to get anyone to listen -- it's good to have someone else singing from the same songbook.
So how is C immune from this? You don't control the actual codegen anymore, and that can even be at runtime now. (Different codepaths for different invocations of the same function, potentially leaking information via timing.)
There's a lot of answers for this, but a simple one is that C gives you (much more) control over the memory hierarchy. A carefully written C program can, for instance, keep things most in or out of cache. High-level languages also abstract bignum math, which in number-theoretic crypto is a source of timing channels.
Yes, the conventional wisdom is that C is less secure than high-level languages. If you're talking memory management, that's correct. DJB does nothing but stack variables for NaCl to avoid performance and potential for memory leaks.
But for side channels, C is almost too high level. For example, it takes assembly code (cpuid) to figure out cache configuration. Even worse, a language like Java or python gives you no control over the memory layout of the key in RAM.
So the right combo in my opinion is a carefully tuned C implementation (possibly with a little assembly or compile-time tweaking). Then add your language bindings to call it from a HLL.
Of course, NaCl isn't written in C; it's written in a combination of C and dynamically-generated assembly (Bernstein wrote his own macro assembler/"high level assembler", qhasm).
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.
I'm not well-versed in crypto libraries, but is there any reason not to use OpenSSL? That's where I turned when I needed a SHA256 implementation (for a C program), and it worked like a charm. Didn't seem too convoluted to use, either. It has been around long enough that just about every platform has it packaged and ready to use, and dynamically linking against it worked fine everywhere I cared to try.
Yes, there's a very good reason not to use OpenSSL to do your own crypto: the only reliable functionality you get from OpenSSL is the crypto primitives themselves. The actual constructions that use those primitives are extremely error-prone. The point of Keyczar, cryptlib, and NaCl is to prevent those errors.
It is extremely easy to use OpenSSL. That is one of the problems with OpenSSL.
OpenSSL has a history of major security bugs. I haven't seen any filed against it recently, and it is widely used, but it gives people the heebie-jeebies, sort of like BIND does. If memory serves it also is a little inflexible if you want to do something a little unconventional.
Now, that said, there are certainly sound engineering reasons to continue to use OpenSSL, and in no way should you use any other library that has not seen extensive, extensive security review in its place. NaCl is certainly included there.
If OpenSSL has the kinds of blatant implementation errors that Graham is alluding to (e.g. memcpy memory corruption problems in ASN.1 parses and padding checks), we all have bigger problems than whether he's right about it being a crappy library. A huge number of critically important systems depend on it.
I don't love OpenSSL's code --- it's a mess with a zillion different authors and styles --- but the bar for finding horrible problems in it is quite high. The position of being the oft-banged-upon default isn't necessarily unenviable; in OpenSSL's case, it means a lot of crap has been shaken out.
The comparison to BIND is superficial; BIND's problems are architectural, OpenSSL's problems stem from it dating back to Eric Young's code, which predates integer overflows and hails from a time when we thought you could mitigate a buffer overflow by malloc'ing instead of allocating on the stack.
Don't use OpenSSL --- it's the wrong level abstraction for lay coders --- but yes, don't bash it for the wrong reasons.
Conceded that technically OpenSSL is much better off than BIND ever was. When I was a lay-sysadmin many years ago, I ran BIND because what else was there? but always in the back of my head was the possibility that someone found Yet Another Hole in BIND. I'm not nearly as concerned about the implementation quality of OpenSSL today; it's been long enough it's probably okay (but at the wrong level of abstraction). But it historically had enough issues to show up on my warning radar as a lay sysadmin, and that meant that I never really trusted it afterward.
True, but there is still a namespace conflict within the security world. Google's Native Client (http://code.google.com/p/nativeclient/) is called NaCl by the developers, and more and more externally as well :P
AMEN!
I've been trying to make this point to people for years, but it has been hard to get anyone to listen -- it's good to have someone else singing from the same songbook.