1
$\begingroup$

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?

$\endgroup$
7
  • 1
    $\begingroup$ 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. $\endgroup$ Commented Feb 3, 2023 at 12:49
  • $\begingroup$ 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 :) $\endgroup$
    – Andrew
    Commented Feb 3, 2023 at 13:18
  • $\begingroup$ 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 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. $\endgroup$ Commented Feb 3, 2023 at 13:38
  • $\begingroup$ 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. $\endgroup$
    – Andrew
    Commented Feb 3, 2023 at 13:50
  • $\begingroup$ 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. $\endgroup$
    – Andrew
    Commented Feb 3, 2023 at 13:50

1 Answer 1

2
$\begingroup$

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.
$\endgroup$
1
  • $\begingroup$ 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:) $\endgroup$
    – Andrew
    Commented Feb 4, 2023 at 19:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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