Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

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?

share|improve this question
    
a larger nonce does not improve security, it just allows more messages to be processed under the same key –  Richie Frame 2 days ago
    
XChaCha implementation (XSalsa20's nonce and ChaCha's diffusion): github.com/lightbit/kripto/blob/master/lib/stream/chacha.c –  LightBit 2 days ago

1 Answer 1

up vote 5 down vote accepted

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.

share|improve this answer
    
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. –  x9c8v7 yesterday
    
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. –  CodesInChaos yesterday
    
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. –  CodesInChaos yesterday
    
Can I use a random nonce with ChaCha? Or the 64 bits will be a limitation? –  x9c8v7 yesterday
    
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. –  CodesInChaos yesterday

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.