node-nacl

Probably the best KDF you'll get right now is scrypt[1]. NaCl did not see common adoption because until a relatively recent distribution called Sodium[2], it was not portable. And I mean really, not portable. Like, just to give an example, suppose you want to use NaCl in Node.js, which is pretty good about accepting C/C++ modules. You have two options today: one doesn't work on a 64-bit system[3] and one isn't C, it's JS which was transpiled with Emscripten[4]. I mean, don't get me wrong: the fact that we can now do this in pure JS via Emscripten is amazing, but yeah, NaCl was not universally buildable and therefore was not reliably deployable, and nobody really wanted to fix it until Sodium came along. [1] https://www.tarsnap.com/scrypt.html [2] https://github.com/jedisct1/libsodium [3] https://github.com/thejh/node-nacl [4] https://gith

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 m