Score:1

XChaCha20-Poly1305 question about IV's

tr flag

I've a question about XChaCha20-Poly1305, from a brute force perspective. Suppose we have the power to brute force crack it. If the IV is known to the attacker and it's only one file. The time needed to crack it's the same if the attacker doesn't know the IV. But if you use the same key for different files with different IV and the attacker doesn't know them, he'd have to crack each file from scratch if the IV isn't known. Am I right?

samuel-lucas6 avatar
bs flag
The time isn't the same between the attacker knowing the nonce and not knowing the nonce in your first scenario. It's just that hiding the nonce doesn't bring meaningful security because the key is already too difficult to brute force. In scenario 2, if the attacker knows you're using the same key, they just have to brute force the nonce instead of the key.
Andrew avatar
tr flag
Yes, I know it's already too difficult, I wasn't clear in my question. Let's forget that it's already two difficult and let's speak hypothetically. In the second scenario, it'll be much more difficult ... I know that with today's computational power is like asking if it's harder to die twice or only once :)
samuel-lucas6 avatar
bs flag
I'm afraid I don't understand the difference between the scenarios though. If the attacker doesn't know the nonce, it will be harder than if they only don't know the key. That's basically the answer to your question. This is arguably a duplicate of a [question](https://crypto.stackexchange.com/questions/101659/how-much-security-is-gained-from-hiding-the-nonce) I asked before, which I knew the answer to but was interested in hearing from others about. Unfortunately, most answers weren't helpful. forest provides the most accurate answer by far.
Andrew avatar
tr flag
That's exactly why I'm asking here, because actually I already found your post, but I didn't find a good answer. I realize this is a touchy subject and probably not many can answer cryptographic questions with certainty. With this topic, I'm assuming that I don't know anything, so I'd like to get others' opinions.
Andrew avatar
tr flag
All I find is that hiding the IV doesn't make it harder to break. And I imagine that's only true for one file for example. Because if you try all the possibilities (let's pretend ), if you have only one encrypted data block, it's probably the same whether you know IV or not (maybe I'm wrong here). But if you have multiple data blocks, even if they use the same key, and because they use different IV (no counter) that the attacker doesn't have. This forces the attacker to start over with brute force methods on each block. Forget the unimaginable time that a brute force procedure would take.
samuel-lucas6 avatar
bs flag
Hiding the nonce does make it more difficult for the attacker. That's why I'm saying forest's answer is the best answer there. Even when the nonce is a counter after the initial hidden value. Assuming they know the protocol, they'll know that the entire file uses a single key. But if the nonce is random each time or to find the initial counter starting point, they have to brute force the nonce, which is large for XChaCha20-Poly1305 obviously. An incorrect nonce means an incorrect HChaCha20 subkey and/or ChaCha20-Poly1305 nonce. Either will cause decryption to fail.
Andrew avatar
tr flag
Okay, thank you. I guess I made the wrong assumption that there is a possible key for each IV. For example, if the IV was all zeros, there was a possible key for decryption that didn't match the original key. I was wrong! I've always believed that not knowing the IV makes things harder, but in the end it doesn't matter. If the forest answer is correct, the IV basically expands the encryption key size if it's not known.
Score:2
bs flag

If the IV is known to the attacker and it's only one file. The time needed to crack it's the same if the attacker doesn't know the IV.

If the attacker doesn't know the nonce, they must brute force it as well as the key. Therefore, it takes longer to perform brute force.

This is simple to explain with XChaCha20-Poly1305 because HChaCha20 is used with the key and part of the nonce to derive a subkey. This subkey and the rest of the nonce are then used for encryption with ChaCha20-Poly1305. This is explained in the Internet Draft.

Furthermore, the ChaCha state looks like this:

       cccccccc  cccccccc  cccccccc  cccccccc
       kkkkkkkk  kkkkkkkk  kkkkkkkk  kkkkkkkk
       kkkkkkkk  kkkkkkkk  kkkkkkkk  kkkkkkkk
       bbbbbbbb  nnnnnnnn  nnnnnnnn  nnnnnnnn

c=constant k=key b=blockcount n=nonce

Thus, hiding a random nonce means a) the attacker doesn't know the key for ChaCha20-Poly1305 and b) they don't know 64 bits of the nonce for ChaCha20-Poly1305, essentially making that part of the state an extension of the secret key:

       cccccccc  cccccccc  cccccccc  cccccccc
       kkkkkkkk  kkkkkkkk  kkkkkkkk  kkkkkkkk
       kkkkkkkk  kkkkkkkk  kkkkkkkk  kkkkkkkk
       bbbbbbbb  nnnnnnnn  kkkkkkkk  kkkkkkkk

c=constant k=key b=blockcount n=nonce

Note the reason it's not 96 bits (the full nonce) is because XChaCha20-Poly1305 involves prepending 4 0x00 bytes. Otherwise, XChaCha20-Poly1305 would need to take a 224-bit nonce instead of 192-bit, which doesn't align with how XSalsa20 was done.

But if you use the same key for different files with different IV and the attacker doesn't know them, he'd have to crack each file from scratch if the IV isn't known.

This is a bit confusing. Assuming the protocol is openly available or able to be reverse engineered, it may be obvious that the same key is being used, which means only the nonce has to be brute forced. Otherwise, the attacker would likely end up trying different keys, meaning brute forcing the key and nonce, which is the same as the first part of your question.

Anyway, it's really doesn't matter. It's standard practice for the nonce to be public, and the security advantage from hiding the nonce isn't 'meaningful' because anything above 256-bit security is unnecessary. The two benefits are:

  1. Saving storage/bandwidth. However, this can also be achieved with a regular counter nonce from 0, which is much simpler.
  2. Limiting metadata. However, a random nonce does this well enough if this is a concern. For many, including existing standards, this isn't a concern.
Andrew avatar
tr flag
Thanks for the reply and for your valuable time. In my implementation the IV's are separated from the files to save space and bandwidth, just that. For the IV I use a counter and a permutation of a random string, which is available but in no way related to the encryption data or key. The IV's are only secret if, for example, the storage files at the cloud (s3) are somehow compromised. And you're right, there are 1.157920892373x10^77 possible permutations for 256 bits key. The number of atoms in the known universe is between 10^78 and 10^82. We're safe:)
I sit in a Tesla and translated this thread with Ai:

mangohost

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.