I'm planning to use the crypto_box() functions of Nacl (or, alternatively, the crypto_box_easy() functions of libsodium) to encrypt messages as part of a client/server protocol. The server has to deal with multiple clients and each message from a client to the server is encrypted using the public key of the server and signed with the private key of the client.

The cypto_box() functions also require me to provide a nonce. The current message number could be used as a nonce–to my understanding, the nonce is necessarily known to an attacker who is capable of keeping track of how many messages were exchanged. Both, the client and server would then maintain a message counter and simply use the newest counter value as a nonce.

However, I must deal with the case where messages are reordered or lost. Therefore I'd send the nonce in plaintext alongside the encrypted message. As long as the same nonce is not used twice, I don't see any problems with this approach. Did I miss out on something?

  • $\begingroup$ Have you read the crypto_box documentation, specifically, the paragraph titled "security model"? Clearly, in the case of incrementing but secret nonces, an attacker could easily guess the nonce since it stays very small, hence one must assume that it becomes public anyway. Therefore, exposing the nonce should not constitute any additional security risk. $\endgroup$ – yyyyyyy Mar 9 '15 at 12:51
  • $\begingroup$ Hence, the answer to my question is No and my reasoning is sound: Since the attacker is able to infer the current nonce–if chosen deterministically–it has no impact on the security of the protocol if the attacker is able to read the nonce directly. By asking this question, I'm just implicitly reassuring myself that the premise actually holds. $\endgroup$ – dsd Mar 9 '15 at 15:24
  • $\begingroup$ Sorry; somehow I didn't realize my comment coincides with your own reasoning. Of course you are absolutely correct. $\endgroup$ – yyyyyyy Mar 9 '15 at 15:34
  • $\begingroup$ @yyyyyyy What about converting your comments in an answer? dsd now has confirmation, but the question is still without answer. $\endgroup$ – Maarten Bodewes Apr 3 '16 at 12:22

The only requirement posed to the nonce in the "Security Model" paragraph of the crypto_box documentation is uniqueness for each pair of communicating parties. In fact, the documentation explicitly recommends incrementing nonces starting from zero (which an attacker could easily brute-force) or random nonces (which need to be transmitted together with the ciphertext anyway).

Therefore, sending the nonce publicly should be secure (unless some underlying primitive is broken, of course).


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.