I have a very simple question. Since XChaCha20 nonces are 192-bit, there's technically no limitation to the max number of message encrypted, since the chances of two random nonces being the same are very very tiny. Is it okay to use the same key, but difference nonces to encrypt large files in chunks? Basically, I read the large file 1KB at a time, encrypt with the same key but random nonce. If the file is 1GB, then I would have used 1000000 nonces. If I encrypted in chunks of 1MB, then I would've used 1000 nonces. Is doing this secure? (Assume everything is authenticated and I use CSPRNGs for nonces)
$\begingroup$
$\endgroup$
8
-
$\begingroup$ Related The security of ChaCha20-Poly1305 with random nonces, Would it be safe to use the message hash as the IV in ChaCha? $\endgroup$– kelalakaMar 26, 2021 at 8:56
-
$\begingroup$ Actually, you don't need that. You can still use the same key and nonce, too $\endgroup$– kelalakaMar 26, 2021 at 10:01
-
$\begingroup$ @kelalaka Just making sure, from what I understand from your last comment is that I just concatenate a counter to the ciphertext before MACing. If one of the blocks was rearranged, then the counter wouldn't be the same and therefore the MAC wouldn't match. Am I right? Thank you. $\endgroup$– Evan SuMar 26, 2021 at 18:28
-
$\begingroup$ Not exactly ( there was a typo that was corrected), they are added into the plaintext to hide. Only the first and last indicators exist in the associated data. You can design one with only the associated data, too. Associated data is only MACed, not encrypted. Libsodium's secretstream API is already implemented for everybody. What is not working for you there? $\endgroup$– kelalakaMar 26, 2021 at 18:34
-
1$\begingroup$ Well, Bernstein is the creator of NaCl you want something more? $\endgroup$– kelalakaMar 26, 2021 at 18:43
|
Show 3 more comments
1 Answer
$\begingroup$
$\endgroup$
6
Yes. Indeed, a "nonce" is a number used once. If you ever reuse a (nonce, key) pair, security breaks catastrophically. For a large chunked file, you can simply use the chunk number as the nonce, as long as you re-key after each file and can keep track of the count.
Libsodium's secretstream API does this internally. If possible, use that, as it's far safer than building your own construction.
-
$\begingroup$ Very good, yet simple explanation. I understand using a "counter" as the nonce is a good idea, but would just randomly generating nonces be safe enough? The chances of a nonce collision is only 1/2**192, which should be minuscule enough not to worry about. $\endgroup$– Evan SuMar 26, 2021 at 2:43
-
1$\begingroup$ Seconded for using the
secretstreamAPI. Building this yourself comes along with a lot of footguns. $\endgroup$ Mar 26, 2021 at 4:48 -
2$\begingroup$ @HACKERALERT, you aren't thinking like an attacker. You're right that collisions aren't a problem, but without other mitigations, random nonces allow a third party to invisibly reorder arbitrary blocks in the stream. "Don't roll your own crypto" applies here. $\endgroup$ Mar 26, 2021 at 4:54
-
1$\begingroup$ Nitpick: there is better wording for this: If you ever reuse a nonce, security breaks catastrophically. to: If ever the (key,nonce) pair reoccurs confidentiality is lost. $\endgroup$– kelalakaMar 26, 2021 at 17:28
-
1$\begingroup$ For anyone interested, some related reading on the complexities of using authenticated encryption for chunked streams: eprint.iacr.org/2015/189.pdf $\endgroup$ Mar 26, 2021 at 19:41