2

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

imdoingmath
  • 25
  • 1
  • 4

1 Answers1

3

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.

samuel-lucas6
  • 1,783
  • 7
  • 17
  • 1
    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? – imdoingmath Jul 19 '22 at 13:01
  • @imdoingmath Yes, I would recommend ChaCha20. – samuel-lucas6 Jul 19 '22 at 16:30
  • 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 – imdoingmath Jul 19 '22 at 17:58
  • @imdoingmath Are you calling a function or have you coded (X)ChaCha20/AES yourself? Sounds like something funky is going on. – samuel-lucas6 Jul 19 '22 at 18:11
  • For ChaCha20 and AES I'm using the node crypto library and for XChaCha I'm using a random implementation I found online which works – imdoingmath Jul 19 '22 at 18:16
  • I'm afraid I don't know anything about that library, although JavaScript is not the best for cryptography. Perhaps try another major library. This is going beyond the scope of the question. – samuel-lucas6 Jul 19 '22 at 19:17
  • @ErikAronesty A random 96-bit nonce is fine if the key is rotated frequently. That's exactly what XChaCha20 is doing under the hood. It's only problematic if you use a single key to encrypt lots of messages. – samuel-lucas6 Jun 15 '23 at 11:14
  • 1
    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. – Erik Aronesty Jun 16 '23 at 16:35