
NaCl: DJB’s new crypto library - there
http://rdist.root.org/2009/07/14/nacl-djbs-new-crypto-library/
======
cperciva
_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.

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

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

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

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

------
SwellJoe
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?

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

~~~
SwellJoe
_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."

~~~
gchpaco
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_.

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

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

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

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

~~~
blasdel
Both OpenSSL and BIND have the unenviable position of being the _defaults_ ,
and thus get banged on constantly and frequently get integrated poorly.

OTOH I think the comparison to BIND is a bit inapt, as OpenSSL was never
historically the pile of poorly-architected shit that BIND was.

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

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

Could be complete paranoia at this point.

------
kqr2
Just in case someone is rusty on their chemistry:

NaCl == Sodium Chloride == Salt

<http://en.wikipedia.org/wiki/Salt_(cryptography)>

~~~
tptacek
I think it's unlikely that the name is based on password hash salts. That term
occurs only very rarely in the cryptographic literature.

~~~
sparky
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

~~~
jrockway
There is also a Common Lisp implementation called NaCL:

<http://www.cliki.net/NaCL>

------
pelle
This looks like a really killer library. I like the ease of use as well. Now
we need Ruby bindings.

