Some gripes about nacl

It's quite interesting to study why crypto_(secret)box requires zero padding. It's not to avoid memory allocation, as tedu suggests, but to make the implementation stupidly simple. For every invocation of crypto_secretbox, NaCl needs to generate a single-use 32 byte key for the Poly1305 MAC. Since the first 32 bytes of the message are zero, NaCl can simply encrypt the entire message with Salsa20, and the first 32 bytes of the resulting ciphertext conveniently become a suitable key for Poly1305. (So when the documentation says the padding has to actually be zero, it's not kidding.)

By making the implementation more complex (some memcpys and special casing of short messages), as libsodium has done for its crypto_secretbox_easy[1], you can avoid the need for this padding.

Personally, I think djb should have avoided exposing this implementation detail in the interface. To simplify the implementation, he could have used the first output block (stream position 0) of Salsa20 only for the Poly1305 key, and then encrypted the message starting with stream position 1, instead of trying to use the first output block for both the Poly1305 key and the message. The implementation would have been only marginally more complex (not as complex as the libsodium implementation, as you wouldn't need special casing). Unfortunately this can't be changed now without breaking interoperability with messages encrypted with the current version of crypto_secretbox.

[1] https://github.com/jedisct1/libsodium/blob/17932c782e5900ac8...

Is nacl deprecated in favor of the libsodium fork? Or are both projects strong and continuing in parallel?

  [libsodium] is a portable, cross-compilable, installable, 
  packageable fork of NaCl, with a compatible API, and an 
  extended API to improve usability even further.

Source: https://github.com/jedisct1/libsodium/blob/master/README.mar...

I see DJB (original nacl creator http://nacl.cr.yp.to/) appears to contribute to libsodium: https://github.com/jedisct1/libsodium/blob/master/AUTHORS

The website for nacl seems to be a bit outdated (many dates seem to refer to 2013), although there is still this tantalizing bit about features in the 'next' nacl release:

  Major features in the next release of NaCl: full PIC support, 
  for easy integration into other languages; Ed25519 signatures 
  (currently available in SUPERCOP); NEON optimizations.

Thanks for any help clarifying this.

As someone who didn't really know what they were doing, I used NaCl recently to write a program to tunnel packets over UDP.

I started by reading the NaCl source and all the introductory material available—the web site, the two NaCl papers ("Cryptography in NaCl", "The security impact of a new cryptography library"), and quickly reviewed a couple of other papers (e.g. to understand deterministic encryption and D-H key exchange). I think the biggest problem I had was to understand nonce generation and handling properly. The "Cryptography …" paper does contain some advice that I ultimately implemented. But I had to think very hard about what it said before I was confident that I was doing what it said. For example, it says:

«…the nonce can be chosen as a simple counter: 0 for Alice’s first packet, 1 for Bob’s first packet, 2 for Alice’s second packet, 3 for Bob’s second packet, 4 for Alice’s third packet, 5 for Bob’s third packet, etc. Choosing the nonce as a counter followed by (e.g.) 32 random bits helps protect some protocols against denial-of-service attacks. In many applications it is better to increase the counter to, e.g., the number of nanoseconds that have passed since a standard epoch in the local clock, so that the current value of the counter does not leak the traffic rate.»

I managed to figure it out, but I would certainly have welcomed a more detailed explanation, and would have been very happy to have help from the code to do the right thing.

In contrast, the cryptography functions were easy enough to figure out and use (with the C API). The only mistake I kept making was specifying the secret key first and the public key second in all my function calls. Once I got used to doing it the other way around, it was fine. Zero-padding the messages was slightly ugly, but I didn't develop any especially strong feelings about it. (Aside: I actually ended up using TweetNaCl, but of course all the documentation is the same.)

I'm very pleased with the resulting code, anyway.

P.S. I looked at libsodium, but greatly preferred the unadorned library.

The tl;dr is: use libsodium: http://doc.libsodium.org/

The easiest way to get round the slightly odd build environment for NaCl is to just use TweetNaCl (http://tweetnacl.cr.yp.to/software.html) which just requires you to drop a single .c/.h file into your project - this isn't as performant as the reference code but in most cases this probably doesn't matter. The libsodium implementation seems overly complicated to me for most uses.

The NaCl API is reasonably simple and is fairly easy to wrap (plug - if anyone is looking for an example have a look at jim-nacl [1] which embeds into Jim TCL)

[1] https://github.com/paulchakravarti/jim-nacl

Paging @tptacek for comment

These are all very legitimate gripes, and even dangers.

One wrapper I used (think Python/Perl/Ruby), the author did not properly understand how the 0-padding was supposed to be implemented. I was scratching my head for a few hours wondering why messages I encrypted were not being received properly. Turns out, bugs in the C padding code.

The discussion of nonces really needs big flashing warning text and icons. I've seen total disasters with code trying to do nonces correctly, or not even understanding why nonces are important (one VPN package I used had the option of using null nonces, as if it were a feature!)

Can anyone comment on the use of formal verification in NaCl? Is it used at all? Would it even be valuable? [0] doesn't mention anything about it.

[0] http://nacl.cr.yp.to/valid.html

Simply put, use the reference nacl implementation only when you really know what you're doing. As with all things crypto it's easy to shoot yourself in the foot, and libsodium makes it a bit harder than reference nacl.

Isn't the fact that nacl is written by such highly reputable guy(in the crypto community) and that it sees relatively lots of review by experts important here ?

Somehow these and other "gripes" about djb software over the years have never been as interesting or entertaining as the ones djb himself has been sharing with us since the 90's. But complaints are to be expected.

Personally I do not care for libsodium, but to each his own.

Instead I chose to study curveprotect, tinysshd (tweetnacl), qremote, etc. as examples to learn from. Realizing that everyone is capable of making mistakes, but some are less likely than others.

Good API design is, like "installability," a critical and often neglected aspect of software engineering. I find that bad APIs are the norm in every area, not just crypto. Audio and video stuff is just hideous.

I used the NaCl crypto for ZeroTier One but basically refactored the code into C++ classes that build like normal modern C++.

I thought this was going to be complaining about salt...

This title a very subtle trap for those who do not read articles. :P

> If nacl picks up that your new CPU has some advanced instructions, it will use them, resulting in a library that won’t work on older CPUs. It’s hard to ship binaries when you’re uncertain of what CPUs they will run on.

Uhm.. What? Isn't this going exactly against all that nacl was ever designed for?

Also, why can't instructions for one CPU be translated/compiled to instructions suitable for another CPU?