17
$\begingroup$

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?

Improve this question
$\endgroup$
2

1 Answer 1

Reset to default
17
$\begingroup$

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.

Improve this answer
$\endgroup$
7
  • 1
    $\begingroup$ Thanks for your answer CodesInChaos. Do you mind adding to your answer a decision as to which published variant of Salsa20, XSalsa20 and ChaCha20 is the most secure to use? I possibly want to try it in messaging software, I think one with a random nonce will work better, then change the nonce every message. $\endgroup$
    – x9c8v7
    Commented Dec 18, 2014 at 9:18
  • $\begingroup$ How to handle nonces should mainly be decided by the requirements of the application. I would avoid keeping nonces between runs of an application, so if you reuse a key beyond application restarts a counter doesn't work well. But if you encrypt a sequence of messages in a communication protocol the key is typically per-connection and a counter works well. $\endgroup$
    – CodesInChaos
    Commented Dec 18, 2014 at 9:23
  • 3
    $\begingroup$ Deciding between Salsa20 and ChaCha is a matter of preference. Salsa20 has the advantage of having competed in eStream, being part of the NaCl library and a (rather limited) proof of security against differential cryptoanalyis. ChaCha has slightly better security per round, a bit more elegant and it's used in a TLS suite. Personally I'd choose ChaCha if either is equally practical to use but might prefer Salsa20 if I'm already using a library where it's implemented. $\endgroup$
    – CodesInChaos
    Commented Dec 18, 2014 at 9:28
  • 1
    $\begingroup$ For a random nonce you need XChaCha or XSalsa20. Finding an XChaCha implementation and making sure it's correct will be harder than finding a correct XSalsa20 implementation. So if you need long/random nonces, Salsa20 might be preferable over ChaCha. $\endgroup$
    – CodesInChaos
    Commented Dec 18, 2014 at 9:32
  • 2
    $\begingroup$ If you have a per session key, you still need a counter to distinguish messages. If you have a per message key (like noise) you don't need a nonce at all. If your protocol fits random nonces, use ciphers which support that. Choosing or designing a good protocol is the important part, choosing between Salsa20 and ChaCha a minor detail. $\endgroup$
    – CodesInChaos
    Commented Dec 18, 2014 at 9:41

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.