Score:2

Crypto

NaCL - should I keep track of expired nonces

Michael

5/3/24, 7:32 AM

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.

309

1 + 0

nonce

Score:2

Crypto

cisnjxqu

5/3/24, 7:47 AM

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

+ 10

Michael

5/3/24, 7:54 AM

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

DannyNiu

5/3/24, 8:40 AM

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

5/3/24, 8:41 AM

Also check out [this](https://crypto.stackexchange.com/a/101505/36960)

samuel-lucas6

5/3/24, 11:52 AM

Threema kept a database of random nonces, and it didn't turn out [well](https://breakingthe3ma.app/).

Michael

5/3/24, 2:42 PM

@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!

Martin Bonner supports Monica

5/3/24, 4:05 PM

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).

ruakh

5/3/24, 6:02 PM

@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!

samuel-lucas6

5/4/24, 8:14 AM

@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.

Michael

5/4/24, 11:34 AM

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.

samuel-lucas6

5/4/24, 12:32 PM

@Michael It was either [this](https://securitycryptographywhatever.com/2023/01/27/threema/) or [this](https://www.cryptography.fm/22). They also did a [talk](https://youtu.be/sthXs4zJ5XU?t=1892) at RWC 2023.

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: NaCL - should I keep track of expired nonces

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.