We know that for ChaCha20 and XChaCha20, the same key can never be used with the same nonce. But let's say I use a random 256-bit key every time... Then the nonce can be whatever because the key is always different. Let's say I set the nonce to be all zeros. As long as the 256-bit key is random, then this setup should be secure since 256-bits is large enough to not be bruteforced or be reused.

Now, let's work backward. Suppose I use Argon2 for key derivation. If I use a 256-bit salt with Argon2, then the output key should have 256-bits of randomness, and if I feed that key into XChaCha20, I theoretically should never run into the same key, and thus, can use a zeroed nonce.

I have three questions:

  1. Is there something wrong with using a zeroed nonce if the key is always random?
  2. In this case, does using a 192-bit nonce for XChaCha20 have any additional benefit?
  3. Is it safe to use a 256-bit salt for Argon2, when the recommended salt is 128-bits?

Context: file encryption

  • $\begingroup$ You need to be careful when encrypting files with (X)ChaCha $\endgroup$
    – kelalaka
    Commented Jan 23, 2022 at 21:03
  • $\begingroup$ Thanks @kelalaka! Using Argon2 with a standard salt, then using HKDF with a 32 byte salt to generate the encryption key and nonce for ChaCha20 is perfect. Maybe make an answer with a quote from that link and I can accept it? $\endgroup$
    – Evan Su
    Commented Jan 24, 2022 at 12:52
  • 1
    $\begingroup$ I don't think we need another answer, I'm pretty sure that SAI Peregrinus can update the answer. Let me ping them. $\endgroup$
    – kelalaka
    Commented Jan 24, 2022 at 13:03

1 Answer 1

  1. Yes. The performance will be terrible.
  2. No, it only further decreases the performance. The point of XChaCha20 is to have a nonce large enough to be able to pick it randomly while still having a 64-bit counter.
  3. Argon2 doesn't use a nonce. It uses a salt. These are different things: a salt is unique per user, and is intended to stay the same between invocations. A nonce is unique per message. The salt isn't intended to provide secret entropy to the output, it merely makes two identical passwords used as input have different outputs. The salt is assumed to be a public input, and Argon2's security analysis doesn't show that it can't be found from the output (because it's directly part of the standard output structure, for one). The entropy of the Argon2 output comes from the input passphrase, not the salt. Using the salt as the entropy input source instead of the passphrase violates the security analysis, so we can't say it's safe.
  4. (from the comments) "Using Argon2 with a standard (per-user/account/similar) salt, then using HKDF with a 32-byte salt (unspecified source) to generate the encryption key and nonce for ChaCha20 is perfect." This can work, but isn't necessary if using XChaCha20. Argon2 is a KDF, and can be used to derive a key from a password safely. XChaCha20 allows the use of a random nonce, so you could just use your OS's secure RNG. If you want to use ChaCha20 (non-X version), then this could help in picking a nonce. Note that the salt must be fixed for HKDF, it's the info parameter that you need to vary to get unique nonce values out securely. This blog post has a good description of why, the short version is that HKDF has a security proof that depends on having a fixed salt value but varying info value to safely output independent results.
  • 1
    $\begingroup$ Could you update your answer with the suggestion that Evan Su found perfect for them? $\endgroup$
    – kelalaka
    Commented Jan 24, 2022 at 13:04

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.