This is based on NaCL. NaCL is an extremely great library that we virtually never recommend because it is very difficult to integrate into most people's dev environments.
Libraries like NaCL, Keyczar, and Cryptlib work by removing all the design choices from cryptography. You don't pick the key sizes, you don't pick the algorithms, you don't even pick what kind of keys you exchange. They implement a whole cryptosystem, as if for some new unreleased version of PGP, subtract the file format, and present it as an API. They're great. They are literally the only way you should be deploying cryptography in your applications.
I think this is a great development, but I am not qualified to say. This sits in a weird place in between a language binding for NaCL and a fork of NaCL. As a bindings package it's an overachiever; as a fork, it seems to have made extraordinarily conservative changes.
You'd really like a real crypto dev --- Matthew Green, Colin Percival, DJB (NaCL's primary author; @hashbreaker on Twitter), Steve Weis, Trevor Perrin, &c --- to say "this is all totally sane, and if you buy the premise of NaCL, go ahead and use this instead.
You'd also really like Sodium to say "this is as much as we're changing from NaCL and nothing else", because what makes NaCL worth building on is the expertise that went into designing it in the first place, which, like me, Frank Dennis probably doesn't have.
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.
As discussed on the mailing-list, there will be a high(er) level API, similar to the C++ API, that doesn't require dealing with input/output being placed at different offsets in a shared buffer.
This is not a rewrite. It uses the reference implementations from NaCl and the same constructions. What it brings over NaCl is a standard build system.
Just a note on the approach taken here: I can't say djb would approve of Sodium, but when I asked him about NaCl's portability, he had this to say:
"The real work here is making everything PIC. Of course, if what matters is the API rather than speed, then achieving PIC is easy: just remove the asm."
Sodium is mostly a "just remove the asm" project, so it seems like djb doesn't hate the concept at least.
I thought he had implemented it in terms of NaCL (I hadn't bothered to look at the code, because I worried I'd decide I was smart enough to endorse it).
Judging from the context below and my limited knowledge of NaCL, this is incorrect. It uses the same algorithms but with the ASM removed. Since, I believe, one of the points of the ASM was removing timing attacks, removing it is not an inherently safe operation. Not saying anyone did anything wrong, just people should be careful and someone should probably check. This is not just a wrapper around NaCL.
Everything that doesn't have assembler versions of all their constant time code (even NaCl under x86/x64) will be vulnerable then. It's possible that compilers start to "optimize" the branchless constructs, but it would almost be malicious as they extremely rare to ever encounter outside of specifically wanting not to branch.
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 ;)
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.
Are you just repeating words you found elsewhere in the thread? You'll be hard pressed to find a crypto system that doesn't require implementations at both ends. NaCL is the library used to implement DNSCrypt, which is pretty much ssh for your DNS queries.
I don't see anything in a Github repo to support this, not with the Microsoft tools. Perhaps it builds under Cygwin and similar, but that's hardly qualifies as "builds on Windows" for practical purposes.
Thanks, I see. Any plans to add static lib generation for Microsoft tools (an nmake script) or is there some gcc-isms in the code? DLLs aren't exactly the most desirable arrangement in a heck of a lot of cases.
Libraries like NaCL, Keyczar, and Cryptlib work by removing all the design choices from cryptography. You don't pick the key sizes, you don't pick the algorithms, you don't even pick what kind of keys you exchange. They implement a whole cryptosystem, as if for some new unreleased version of PGP, subtract the file format, and present it as an API. They're great. They are literally the only way you should be deploying cryptography in your applications.
I think this is a great development, but I am not qualified to say. This sits in a weird place in between a language binding for NaCL and a fork of NaCL. As a bindings package it's an overachiever; as a fork, it seems to have made extraordinarily conservative changes.
You'd really like a real crypto dev --- Matthew Green, Colin Percival, DJB (NaCL's primary author; @hashbreaker on Twitter), Steve Weis, Trevor Perrin, &c --- to say "this is all totally sane, and if you buy the premise of NaCL, go ahead and use this instead.
You'd also really like Sodium to say "this is as much as we're changing from NaCL and nothing else", because what makes NaCL worth building on is the expertise that went into designing it in the first place, which, like me, Frank Dennis probably doesn't have.