2
$\begingroup$

I store the ciphertext and the nonce in a SQL database.

If I decrypt the ciphertext change it and encrypt it again I generate a new nonce, so that I do not encrypt two different plaintexts with the same nonce. After encrypting the updated plaintext I store the ciphertext and the new nonce back to the database.

My question is: Should I keep track of the expired nonces so that no other plaintext is ever encrypted with the same nonce again?

I think about doing that because I assume that an attacker could have stolen a version of the database entries, and if he gets a newer version of the data and a nonce is reused because I do not keep track of expired nonces the attacker potentially gets two different ciphertext with the same nonce, and this could be a potential risk in my understanding of the NaCL library.

Improve this question
$\endgroup$

1 Answer 1

Reset to default
2
$\begingroup$

Storing all old nonces is definitely a way of achieving nonce re-use freedom, but it's of course quite costly.

You could also use a e.g. 64bit counter instead as a nonce:

  • start at 0
  • increment the nonce each time you encrypt something
  • check for overflows when incrementing (if the counter overflows: abort!)

that will also ensure that you don't re-use nonces, and you won't have to store all old nonces. This is also roughly what TLSv1.3 does: https://datatracker.ietf.org/doc/html/rfc8446#section-5.3

Improve this answer
$\endgroup$
10
  • $\begingroup$ Is using a 64 bit / 8 bytes nonce sufficient, I think the NaCL nonce should be 24 bytes if I look at the nonce length constant in the nacl library: github.com/dchest/tweetnacl-js#naclboxnoncelength--24 $\endgroup$
    – user109145
    Commented May 3, 2023 at 7:54
  • 1
    $\begingroup$ @samuel-lucas6 in my understanding the problem with the stored nonces in the threema case is that they could not be migrated to new devices, so it is possible to have the nonces used again with new messages? i think that should not be a problem in this case because the nonces are stored in the online database? and thank you for this great link! $\endgroup$
    – user109145
    Commented May 3, 2023 at 14:42
  • 1
    $\begingroup$ If the NaCL nonce is 24 bytes (192 bits) and you have a source of good random numbers, then just using a random nonce is adequate (no need to check for overflow). The chance of collision will be negligible unless you encode 2**96 texts (which at 1 encryption per nano second on a billion computers will take about 2000 years). $\endgroup$
    – Martin Bonner supports Monica
    Commented May 3, 2023 at 16:05
  • 1
    $\begingroup$ @MartinBonnersupportsMonica: I think you're slightly overstating your case. If I'm not mistaken, the chance of collision reaches 1 in 10,000 already at 2**90. So at a rate of 1 encryption per nanosecond on a billion computers, you have a small-but-non-negligible chance of collision after only 40 years. :-P . . . Though of course, that's only useful to an attacker who's saved all octillion ciphertexts! $\endgroup$
    – ruakh
    Commented May 3, 2023 at 18:02
  • 1
    $\begingroup$ @Michael It was either this or this. They also did a talk at RWC 2023. $\endgroup$
    – samuel-lucas6
    Commented May 4, 2023 at 12:32

Your Answer

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