1
$\begingroup$

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?

Improve this question
$\endgroup$

1 Answer 1

Reset to default
2
$\begingroup$

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)

Improve this answer
$\endgroup$
5
  • $\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, 2019 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, 2019 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, 2019 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, 2019 at 13:22
  • $\begingroup$ Thanks @FrankDenis, makes sense :+1 $\endgroup$
    – Woodstock
    Nov 26, 2019 at 13:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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