Is that why, or is it because nobody can find it? At first I thought you were talking about google's Native Client, and it's the Google results for 'nacl' or 'python nacl', etc. have both the crypto lib. and the browser vm interspersed.

I'm the author of RbNaCl, the Ruby binding to Sodium. RbNaCl wouldn't be possible without Sodium, because RbNaCl is written as a Ruby FFI binding and thus requires a shared library. Sodium builds a shared library. NaCl does not. Let me explain why...

There are many problems that hinder building language bindings to NaCl. See, for example, node-nacl:

https://github.com/thejh/node-nacl

See the giant warning in bold at the top:

"WARNING: This library DOES NOT WORK on 64-bit systems, and there's nothing I can do about it before the next version of NaCl is available."

Much of the assembly in NaCl is presently NOT position independent code which causes many of these sorts of problems. djb has admitted as much and sought to fix these sorts of problems.

Here is what djb had to say in email recently:

"More language support. 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."

At the very least, djb recognizes that removing the ASM is a simple and valid option for achieving PIC now without additional work on the assembly code. In the meantime he is doing a lot of that work inside SUPERCOP.

There's also the elephant in the room: Windows. NaCl doesn't support Windows. NaCl will likely never support Windows. Sodium supports Windows.

Part of the problem here is that DJB has more than one research goal, and the most important of those goals is making this stuff as fast as possible; his omnibus goal is to get high-security crypto implementations so fast that they can be deployed universally in every application.

As a result, all this stuff is excruciatingly tuned.

Yeah, ASM is also probably the only realistic way you can guarantee constant time (i.e. guarantee a C compiler won't do something crazy behind your back)

In the meantime, people continue to use OpenSSL because using NaCl is too hard

> WARNING: This library DOES NOT WORK on 64-bit systems, and there's nothing I can do about it before the next version of NaCl is available.

FWIW, that warning is...incorrect. Anyone who actually wants to use NaCl with Node.js (and we do) can trivially get a 64-bit build (it's even done through Python). I don't disagree that the original author of node-nacl wasn't skilled enough to do it though.

> There's also the elephant in the room: Windows. NaCl doesn't support Windows.

Say what? NaCl supports Windows just fine – it's just djb's 'do' build script that doesn't, along with how to get a random number. There's absolutely nothing to prevent anyone from using NaCl on Windows, if they are willing to integrate it into a normal Windows build system (which is...trivial) and make a few, trivial, API updates.

----

Having addressed those mis-understandings, Sodium is a welcome development and will certainly make it easier for people to develop bindings to NaCl.

> Say what? NaCl supports Windows just fine – it's just djb's 'do' build script that doesn't, along with how to get a random number

You realize you're describing exactly what Sodium fixes (portable build system + randombytes for Windows), right? That was my original point.

> FWIW, that warning is...incorrect.

Or you have some fundamental flaw in your deployment now. Just because it compiles dosen't mean it's not vulnerable to say, a timing attack.