2
$\begingroup$

Is XChaCha20 with 256 bit key and 192 bit nonce more secure than 128 bit key 128 bit key nonce AES, due to using larger key/nonce sizes? Isn't it supposed to be faster due to being a stream cipher? (in my implementation in turned out to be faster)

Any documentation or sources for further guidance? Thanks

$\endgroup$

1 Answer 1

3
$\begingroup$

Firstly, let me say that every time I mention ChaCha20, the same applies to XChaCha20 because the security is the same. XChaCha20 uses ChaCha20 internally, the only difference is that it uses this function called HChaCha20 to derive a subkey, which is what allows for the larger nonce. You can read more about it here.

Is XChaCha20 with 256 bit key and 192 bit nonce more secure than 128 bit key 128 bit key nonce AES, due to using larger key/nonce sizes?

Yes, you can make a strong argument for XChaCha20 being more secure than AES-128.

ChaCha20 has a higher security margin than AES, software AES implementations can be susceptible to cache-timing attacks (not that relevant though given hardware support is quite common now), and a 256-bit key is generally recommended for post-quantum security. 128-bit keys can also allow for batch/multi-target attacks, which is where you attack many users in a system at once.

AES has received more cryptanalysis (partly because it's been around longer), but ChaCha20 has good heritage since it's related to Salsa20, which was a finalist in the eSTREAM competition. ChaCha20 is also used by many well-known protocols, such as TLS 1.3.

The larger nonce size doesn't necessarily matter for security; it depends on the application and how frequently the encryption key is being rotated. 128 bits is enough to randomly generate nonces, but 192 bits gives you some extra leeway.

If you're using a unique key each time, you can probably get away with a shorter nonce (e.g. 96 bits). However, using a 192-bit random nonce can be considered an alternative to SIV mode, which is misuse resistant and sometimes used for key wrapping. The nonce size can also allow you to build an SIV implementation.

Isn't it supposed to be faster due to being a stream cipher? (in my implementation in turned out to be faster)

AES and derivatives will typically be faster due to hardware support. However, without hardware support, ChaCha20 should be faster, which is why it's been used on mobile devices. If you can't guarantee hardware support, ChaCha20 makes a lot more sense, and it's certainly not a slow algorithm.

Finally, XChaCha20 is actually slightly slower than regular ChaCha20 due to the subkey derivation. So, if you don't need random nonces, it may make more sense to use ChaCha20 instead.

$\endgroup$
8
  • 1
    $\begingroup$ Thanks a lot!!! This is the answer I was looking for! "XChaCha20 is actually slightly slower than regular ChaCha20" - I tried testing ChaCha20, XChaCha20 and AES, and my results were ChaCha20 was the fastest, then XChaCha20 is a bit slower, and AES-128 is the slowest. But in terms of speed and security ChaCha20 seems like the best choice right? $\endgroup$ Commented Jul 19, 2022 at 13:01
  • $\begingroup$ @imdoingmath Yes, I would recommend ChaCha20. $\endgroup$ Commented Jul 19, 2022 at 16:30
  • $\begingroup$ I'm not sure if my implementation is correct, but for XChaCha20 the execution time is around 11ms, for ChaCha20 and AES it's around 12ms. But when using the node crypto library to implement chacha20, half of my execution times are around 0.001 ms and other half are around 12ms, although this only happens when I convert the decrypted text to utf8, although im doing the same thing using same library for aes and those results are consistent. Do you know why this is happening? Thanks $\endgroup$ Commented Jul 19, 2022 at 17:58
  • $\begingroup$ @imdoingmath Are you calling a function or have you coded (X)ChaCha20/AES yourself? Sounds like something funky is going on. $\endgroup$ Commented Jul 19, 2022 at 18:11
  • 1
    $\begingroup$ ok, phrased it better: if you're not using new keys often, and you're using random iv's ... always use a long 192 bit random iv, don't use a short iv. $\endgroup$ Commented Jun 16, 2023 at 16:35

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.