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)
Asked
Active
Viewed 1,026 times
1
-
Related The security of ChaCha20-Poly1305 with random nonces, Would it be safe to use the message hash as the IV in ChaCha? – kelalaka Mar 26 '21 at 08:56
-
Actually, you don't need that. You can still use the same key and nonce, too – kelalaka Mar 26 '21 at 10:01
-
@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. – Evan Su Mar 26 '21 at 18:28
-
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? – kelalaka Mar 26 '21 at 18:34
-
OK, I completely understand now, thank you. Well, I want to use an audited cryptography library such as Monocypher. While Libsodium is well analyzed, I am somewhat of a paranoid and I think Monocypher is more secure, because it has been audited by Cure53. Monocypher does provide a streaming interface, but it is hard to implement and I don't want to roll my own crypto by working with raw ChaCha20 and Poly1305. So, I'm working with the foolproof Monocypher lock() function. But I can't load a large file into memory, so I have to do it in chunks. – Evan Su Mar 26 '21 at 18:40
-
Your answer in that link is exactly what I want to do. Sorry, I didn't see it at first. – Evan Su Mar 26 '21 at 18:41
-
1Well, Bernstein is the creator of NaCl you want something more? – kelalaka Mar 26 '21 at 18:43
-
No one's perfect. NaCl/Libsodium is probably very secure, but I'm just asking a generic question and not asking for software recommendations :) – Evan Su Mar 26 '21 at 18:49
1 Answers
4
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.
SAI Peregrinus
- 5,836
- 19
- 26
-
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. – Evan Su Mar 26 '21 at 02:43
-
1Seconded for using the
secretstreamAPI. Building this yourself comes along with a lot of footguns. – Stephen Touset Mar 26 '21 at 04:48 -
2@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. – Stephen Touset Mar 26 '21 at 04:54
-
Thanks for pointing that out. I didn't realize that, although it seems so obvious to me now. – Evan Su Mar 26 '21 at 13:11
-
1Nitpick: 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. – kelalaka Mar 26 '21 at 17:28
-
1For anyone interested, some related reading on the complexities of using authenticated encryption for chunked streams: https://eprint.iacr.org/2015/189.pdf – Stephen Touset Mar 26 '21 at 19:41