Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.
Sign up to join this community
The idea of crypto_box API in NaCl library is to shield the programmer away from the technical details and provide easy to use functions for encrypting and encrypting messages.
Given what I've just written, I do not understand why the idea of nonce is exposed in this API. Explaining what nonce is and how to use it takes up a significant portion of the documentation and it is quite possible to get this wrong. Wouldn't it be better to just generate a random bytestring under the covers?
The article on NaCl by its authors touches this subject. I'll quote here the relevant bit:
Nonces. The crypto_box API leaves nonce generation to the caller. This is not meant to suggest that nonce generation is not part of the cryptographer’s job; on the contrary, we believe that cryptographers should take responsibility not just for nonces but also for other security aspects of high-level network protocols. The exposure of nonces simply reflects the fact that nonces are integrated into high-level protocols in different ways.
It might seem simplest to always generate a random 24-byte nonce n, and to transmit this nonce as part of the authenticated ciphertext; 24-byte random strings have negligible chance of colliding. If ciphertexts are long then one can tolerate the costs of generating this randomness and of expanding each ciphertext by 24 bytes. However, random nonces do nothing to stop the simplest type of forgery, namely a replay. One standard strategy to prevent replays is to include an increasing number in each packet and to reject any packet whose number is not larger than the number in the last verified packet; using these sequence numbers as nonces is simpler than giving each packet a number and a random nonce. On the other hand, choosing public nonces as sequence numbers means giving away traffic information that would otherwise be somewhat more expensive for an attacker to collect. Several different solutions appear in the literature; constraints on nonce generation are often tied directly to questions of the security and privacy that users expect.
Current applications of NaCl, such as DNSCurve and CurveCP, have different requirements regarding nonces, replays, forward secrecy, and many other security issues at a higher level than the crypto_box API. A nonceless API would require higher-level complications in all of these applications, and would not simplify their security analysis.
