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.
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.
"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.
The actual crypto in this is DIY?
No. From the linked page: "Sodium uses the same implementations of crypto primitives as NaCl".
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 ;)
† Definitions of "trivial" including "not requiring understanding any of the details of a Unix toolchain at any stage of adoption"
I just looked at NaCL. It only works if both sides use it, but data at rest isn't the big problem. Servers are.
And this doesn't work if you want to make a replacement for ssh.
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.
https://github.com/jedisct1/libsodium/tree/master/dist-build
The end result on Windows is a native DLL library.
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.