Some gripes about nacl

And even when used properly, people always ended up writing wrappers allocating temporary buffers and moving data around in order to add/trim these bytes.

And when people start writing wrappers, it usually means that there is something wrong with the API.

For this reason, libsodium fully supports the crypto_box and crypto_secretbox in a compatible way, but doesn't document them in favor of the "easy" interface, which basically does what everybody was reinventing when writing wrappers for these functions.

How to generate nonces for each operation is described in the libsodium documentation. There are legitimate cases for having full control over the nonce, such as the dnscurve and dnscrypt protocols.

Some bindings such as the Swift bindings (Swift-Sodium) have the box() operation generate and return a nonce in addition to the ciphertext. Less flexible than leaving the responsibility to the developer, but definitely safer, and something that might be added to the library itself. On the other hand, adding more and more functions to do the same thing (because breaking backward compatibility is not an option) isn't good either.

By not providing a simple way to achieve something, users end up copying/pasting random code and inventing their own crypto.

Additional functions that libsodium provides over NaCl were added after observing how developers were using NaCl in actual projects.

When you see projects that allocate temporary buffers to store signed messages, and immediately discard everything because all they actually need is the signature, you realize that developers have to work around limitations of the NaCl API.

When the maintainer of the Go bindings reports memory corruption, which turned out to be due to sign_open() requiring an output buffer larger than the unsigned message you might blame him for not having read the fine print in the NaCl documentation. But maybe the API should better match what feels intuitive to developers instead.

And when developers systematically write wrappers (for example around box() and secretbox() functions) to work around the same issues, it probably means that API could be improved.

Adding convenience functions addressing very common needs to libsodium instead of having everybody rewrite their own implementation makes it less confusing and eventually less dangerous.

For example, the signature system was a prototype that shouldn't be used any more. The portable AES128 implementation produces incorrect output on some other platforms, one of the Curve25519 implementations performs out of bounds memory accesses, and one of the poly1305 implementations will produce incorrect output if your application changes the FP rounding mode. CurveCP was also a fantastic idea, but the NaCl implementation was just a proof of concept that cannot really be used in actual projects.

But would you rather have djb spend time addressing qmail compilation issues on Ubuntu 14.10, or keep making significant advances in applied cryptography (and security in general) instead?

In addition to organizing competitions, the amount of game-changing publications he made or contributed to is very impressive. And it might not have been the case if he didn't move on from software he wrote years ago.