Introducing Sodium, a new cryptographic library

In what way is NaCL difficult to integrate into existing dev environments? I've not personally used it before, but I've been looking for a library that abstracts away some of the difficulty of cryptography (granted you can't hide it all) and NaCL appears to label itself as such.

While the people you've mentioned haven't been keeping an eye on it, Jean-Philippe Aumasson has. There have been a lot of other "mid-level" crypto people who have been keeping an eye on it as well and giving feedback to Frank. For example, at one point Frank switched out the default random number generator to use XSalsa20 instead of /dev/urandom. When this was pointed out, Frank addressed it by switching back to /dev/urandom (and a separate codepath for Windows)

Note: I've talked to Matt Green about Sodium. About all he had to say was as soon as you modify NaCl, you've violated the djb warranty ;)

This looks like new development that's just API-compatible with NaCL though, right? Which feels a little strange.

The reason I'm drawn to the work of DJB is because of his fanatical attention to security-related detail. He wrote and released his own high performance mail server, DNS server, web server, and logging replacement during a period of time when server-side software was plagued with exploitation, and people have only ever found, what, two somewhat minor bugs? Ever?

So what he creates is almost always amazingly solid, but for all his attention to security perfection, his software is also amazingly unusable. Want to run publicfile? First, forget everything you know about standard unix directory structures, because DBJ doesn't like them.

I feel somewhat the same way about NaCL. We can bet the lives of our first born children that the implementation won't suffer any of the bugs that OpenSSL has over the years. Side channel attacks, memory corruption bugs, and timing problems will almost certainly be nonexistent, and someone could probably do their PhD thesis on documenting why.

But like his other software, NaCL has weird usability quirks. This project points out that some of those quirks were certainly manifest in the implementation, but some of them shine through the API itself as well. Like his other software, my sense has been that interacting with NaCL is something that we would almost have to put up with in order to avail ourselves of DJB's greatness, rather than simple joy.

So a rewrite that's API compatible isn't super immediately appealing to me, in the same way that I don't think I'd be particularly drawn to an interface-compatible version of qmail or publicfile that was written by someone else, when the value was in DJB having written them to begin with rather than the interface (the horror!) they provided.

Although to be fair, it's certainly not as if anything else is that much more usable in this world right now.

s/elliptical/elliptic/ Thanks for using libsodium!

DJB's NaCL is an academic project that dates at least back to 2008.

It's not quite as bad as Maxima (http://en.wikipedia.org/wiki/Maxima_%28software%29), though, where it almost feels like the project was intentionally named in a way to make googling difficult.

NaCL/Sodium would not have been deployable in Mega's design. I agree with everything else you say, though!

Unfortunately, like NaCl, it's missing 2 common and critical functions:

    1. Password-based key derivation
    2. Persistent key storage

So developers are still expected to work out those 2 problems and will reliably screw them up.

Keyczar is a library with similar goals to NaCl: relative ease-of-use for authenticated encryption.

NaCl is using more modern cryptographic algorithms (e.g. XSalsa20, Poly1305, and Curve25519). These provide faster encryption with smaller keys.

The elliptic curve cryptography, most notably, provides keys an order of magnitude (or two) smaller than what's available today with Keyczar/NaCl.

Also, the NSA recommends you switch from RSA to ECC:

http://www.nsa.gov/business/programs/elliptic_curve.shtml

Keyczar has support for Java, Python, and C++ and uses the usual suspect standardized algorithms: AES, RSA, DSA, HMAC-SHA1. Google has been pretty active in maintaining Keyczar lately. ECC support should be added at some point.

As bascule said, NaCl / Sodium are using DJB's suite of algorithms, which are going to be faster and have smaller key sizes.

you can chroot yourself away from access to /dev/random

Take a look at arc4random() implementations for a hint. The generator has to switch to a new key after (in the OpenBSD implementation, too lazy to check other implementations now) 1600000 bytes of output. How do you switch to a new key? OpenBSD implemented a sysctl to retrieve the output of the kernel prg. This is great, as it perfectly works in a chroot()ed environment.

Other operating systems don't necessarily provide the same facility. They will try accessing /dev/urandom, and if it doesn't exist, revert to something pretty bad, like read whatever is on the stack and use that as a key.

Sodium provides randombytes_random(), randombytes_uniform() and randombytes_buf() that you can use as drop-in replacements for arc4random(), arc4random_uniform() and arc4random_buf(). On Unix, the file descriptor to /dev/urandom will be kept open, and accessible after a chroot() call. On Windows, the crypto services provider will be transparently used instead.

SSH is a good example of the kind of thing that can't use high-level crypto libraries, because the constructions required to implement SSH are part of the specification.

We're all waiting for Daniel Bernstein to replace SSH, but it hasn't happened yet.

Sodium is effectively a fork of NaCl, and is new.

Nobody uses it, because it lacks bindings to common languages, which is the problem this is solving.

Your key setup leaves a whole lot to be desired. (There's a very real reason that PBKDF2 exists.) Bad crypto libs like this are the EXACT reason that things like NaCl and KeyCzar were created.

Please don't do things like this.

PS: It's also not clear if you're doing the HMAC check in a time-invariant manner: https://github.com/jsdalton/secrets.py/blob/master/secrets/c...

See: http://codahale.com/a-lesson-in-timing-attacks/

Stop using this and start using Sodium, which is more secure than your wrapper library in significant ways that illustrate why people shouldn't think of this stuff as "jargon" that they can just write wrappers for; for instance:

* It generates encryption keys insecurely instead of using a cryptographically secure KDF

* It leaks timing information on the MAC comparison

* It makes verification of messages optional; verification should never be optional (in your case, when verification is disabled, I think you have the CBC padding oracle vulnerability)