It seems that crypto_box_easy, generates a random nonce and appends it to the cipher text in libsodium.

I understand using the same nonce with the same key can be catastrophic with salsa20poly1305, as such is it bad practice to re-use the same public/private (static) curve25519 keys when using crypto_box_easy?

Is it safe enough to assume that libsodium will ensure a random nonce is always used, or should curve25519 keypairs be regenerated on each use?


crypto_box_easy() doesn't generate a random nonce. But as documented, using a random nonce is safe, and can be done using randombytes_buf(nonce, sizeof nonce);. It's still the application's responsibility to include that nonce in the payload.

Alternatively, the more recent secretstream API automatically creates and attaches a nonce, and can encrypt a sequence of messages without having to care about the nonce at all.

(that being said, this is a programming question, so cryptography.stackexchange may not be the best place for it)

  • $\begingroup$ Ah my confusion was in part due to Swift-Sodium, in that authenticated public key boxes (crypto_box_easy), are provided a random nonce in the call self.nonce() - I guess in the c lib one must do this manually. I am working to understand this so that I can write up some documentation for Swift-Sodium. So in closing, it's safe to reuse public/private key pairs more than once, assuming a random nonce is used, as it is in swift-sodium? $\endgroup$ – Woodstock Nov 26 '19 at 13:09
  • 1
    $\begingroup$ Yes, a key can be reused as long as a (key, nonce) tuple is not reused. Swift-sodium does that automatically, and intentionally hides internal implementation details, including in the documentation. Users are not even expected to know what a nonce is. Ultimately, the Swift-sodium API should work with libhydrogen/libsodium2 with no changes. $\endgroup$ – Frank Denis Nov 26 '19 at 13:16
  • $\begingroup$ Yup makes sense, I am trying to understand all of these things in detail so I can write good quality docs for Swift-Sodium. Why do are you aiming to make swift-sodium so easy to use? The user in C must generate his own nonce, why make it easy for the swift dev? -- Or maybe the better question is, why not include a random nonce as part of crypto_box_easy, ensuring safer use in C... Folks will probably regularly re-use key pairs generated in apps, because pub/priv key pairs tend to be swapped. So it's safer to provide an automatic random nonce in the implementation I think. $\endgroup$ – Woodstock Nov 26 '19 at 13:18
  • $\begingroup$ Backward compatibility. The C libsodium API cannot be changed at this point. The Swift wrappers are more recent and didn't have the same constraints. In libhydrogen, nonces are automatically generated and included, and the box API is gone. $\endgroup$ – Frank Denis Nov 26 '19 at 13:22
  • $\begingroup$ Thanks @FrankDenis, makes sense :+1 $\endgroup$ – Woodstock Nov 26 '19 at 13:25

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.