1
$\begingroup$

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)

$\endgroup$
8
  • $\begingroup$ Actually, you don't need that. You can still use the same key and nonce, too $\endgroup$
    – kelalaka
    Mar 26 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 Su
    Mar 26 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$
    – kelalaka
    Mar 26 at 18:34
  • 1
    $\begingroup$ Well, Bernstein is the creator of NaCl you want something more? $\endgroup$
    – kelalaka
    Mar 26 at 18:43
4
$\begingroup$

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.

$\endgroup$
6
  • $\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 Su
    Mar 26 at 2:43
  • 1
    $\begingroup$ Seconded for using the secretstream API. Building this yourself comes along with a lot of footguns. $\endgroup$ Mar 26 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 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$
    – kelalaka
    Mar 26 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 at 19:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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