Dancing confusion with Daniel J. Bernstein's stream ciphers

Question

I know of Salsa20 which won the ESTREAM competition. This is dated of 25 Dec 2007.

There is also the ChaCha20 stream cipher (cr.yp.to/chacha.html). This claims to increase the amount of diffusion per round. This is dated 28 Jan 2008.

Then there is another variant called XSalsa20 which has a 192 bit nonce instead of 64 bits. This is dated 4 Feb 2011. I'm not sure if it contains the diffusion per round improvements from ChaCha20 though.

Question is, which variant of these is the most secure to use? I do not care about speed. It would be really nice if cryptographers would just number their cipher versions/improvements as 1.0, 1.1, 1.2 so people know which is the latest algorithm easily.

On one hand, a 192 bit nonce with XSalsa20 sounds more secure than a 64 bit one. Maybe someone can explain the advantage of that? Would there be an advantage in using a 256 bit nonce which would keep it consistent with the key size? On the other hand, the better diffusion per round of ChaCha20 sounds like a good thing to have as well compared to the original Salsa20. Could a combination of the improvements in XSalsa20 and ChaCha20 be made?

Answer 1

XSalsa20 uses the same cryptographic core as Salsa20 and comes with a security proof that it's secure if Salsa20 is secure. It doesn't use the core of ChaCha and thus has worse diffusion.

The way XSalsa20 works is that it hashes its 256 bit key and the first 128 bits of the nonce using HSalsa down to a 256 bit key and then uses that key together with the remaining 64 bits of the nonce in Salsa20. You can find the details in the paper Extending the Salsa20 nonce.

The problem with nonces is that you must be sure that you never reuse one. With a 64 bit nonce a counter works well, but a counter is stateful. If you want a stateless nonce, the usual approach is to generate a random one, and assume that collisions are sufficiently unlikely to happen. Assuming uniqueness with a random 128 bit value is pretty safe, but with a random 64 bit value collisions become likely even with a moderate number of messages. So you can't use random 64 bit nonces. But if you have a 192 bit nonce, you can randomize it.

Thus the increased nonce size isn't a security improvement, but a feature that allows random nonces.

In principle it's possible to use the same nonce extension technique with ChaCha, but Bernstein didn't publish a specification. In my answer to Can I use the ChaCha core as a 256-bit to 256-bit one-way function? I describe how to construct HChaCha from ChaCha, in the same way HSalsa20 was built from Salsa20. Combining HChaCha and ChaCha into XChaCha is straightforward.