2

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.

1 Answers1

2

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

ambiso
  • 706
  • 4
  • 12
  • 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: https://github.com/dchest/tweetnacl-js#naclboxnoncelength--24 –  May 03 '23 at 07:54
  • 64 bit nonce is sufficient, overflow is quite unlikely. Even 64-bit x86 chips don't support full 64-bit physical memory address space, that's how sufficient a 64-bit counter is. Defending against a counter overflow is good nonetheless. – DannyNiu May 03 '23 at 08:40
  • Also check out this – DannyNiu May 03 '23 at 08:41
  • Threema kept a database of random nonces, and it didn't turn out well. – samuel-lucas6 May 03 '23 at 11:52
  • 1
    @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! –  May 03 '23 at 14:42
  • 1
    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). – Martin Bonner supports Monica May 03 '23 at 16:05
  • 1
    @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! – ruakh May 03 '23 at 18:02
  • @Michael The authors of the paper said having a database of random nonces was a bad idea on podcasts. I haven't read the full paper. – samuel-lucas6 May 04 '23 at 08:14
  • Thanks for the replies, is there a chance to get a link to the podcast @samuel-lucas6? I think I will implement it without storing the nonces in the database. –  May 04 '23 at 11:34
  • 1
    @Michael It was either this or this. They also did a talk at RWC 2023. – samuel-lucas6 May 04 '23 at 12:32