6
$\begingroup$

I've written implementations of Salsa20 and ChaCha that accept 384 and 448 bit keys. It was fairly trivial to implement, the 'sigma' constant is replaced with key material, and the counter, (which was initialized at 0), rotates and can be initialized at any value. So along with the 64 bit vector, the entire 512 bit state can now be initialized via a key/vector.

This does not affect the performance in any way, and if a key is constructed using key + sigma + 0, the output aligns with an implementation that uses a 256 bit key. Provided that the key used is created using a strong PRNG, and the values that replace the constant are sufficiently asymmetric, this should not present a problem, as the constants function seems to be purely to reduce symmetry.

Is there anything incorrect in the description given above?

One other question: I am considering extending max rounds to 24, I have looked at the mathematical model and it seems that this should not do anything other than further diffuse the input. Is that correct?

| improve this question | | | | |
$\endgroup$
  • $\begingroup$ "Is there something I'm not seeing here" ? Yes... extending the key beyond 256 bits is entirely redundant. $\endgroup$ – hunter Nov 9 '14 at 18:40
  • 1
    $\begingroup$ Messages can be stored indefinitely.. Can you guarantee that the processing power required to break a 256 bit key will not exist in 25 years? So.. if you can extend the key size, without impacting performance, why not do it? $\endgroup$ – JGU Nov 9 '14 at 18:45
  • $\begingroup$ @John Will you memorize 448-bit random key? $\endgroup$ – LightBit Nov 9 '14 at 18:49
  • $\begingroup$ @LightBit No, can't memorize a 256 bit key either, that's why we store keys on disk.. My meaning was that an adversary can store them indefinitely, and in fact, massive volumes of our communications are being collected and stored. $\endgroup$ – JGU Nov 9 '14 at 19:05
  • 3
    $\begingroup$ @hunter I learn by reading the spec, studying an existing implementation, then writing my own, and trying to figure out how it all works.. it interests me, it's an experiment, and I am not asking anyone to adopt the things I am writing. I will continue to expand my little open source library, whether you like it or not. If it means I am met with hostility on these forums, I just won't ask questions here anymore.. kind of defeats the purpose of this forum though. $\endgroup$ – JGU Nov 10 '14 at 18:47
4
$\begingroup$

You are correct about extending number of rounds. It is safe to increase number of rounds. In most cases it will increase safety margin.

Removing constants doesn't seem to be a good idea to me, as Salsa20 and ChaCha don't have any round constants. Purpose of constants is also to reduce number of bits that can be controlled by attacker, however key is not assumed to be controlled by attacker. Constants also separate different key lengths. I'm also concerned about sliding attacks, however I don't know, if they are applicable to Salsa20 and ChaCha as they are not a block ciphers.

Setting start value of counter with key will cause same block outputs with different keys at some points as counter will change key.

Even if replacing constants and counter with key is secure, setting 448-bit key into Salsa20 or ChaCha doesn't guarantee 448-bit security. For longer keys cipher (permutation) has to be stronger. Best attack on Salsa20 with 128-bit key breaks 7 rounds, while with 256-bit key it breaks 8 rounds. Also see Keccak permutation distinguishers.

Mouha and Preneel proofed that 15 rounds of Salsa20 is 128-bit secure against differential cryptanalysis. This means Salsa20 with 15 rounds and 448-bit key could possibly be broken with differential cryptanalysis with complexity of about 128-bits.

You could use XSalsa20 to extend key (instead of nonce) by 128-bits. This would be at least as secure as 256-bit Salsa20.

| improve this answer | | | | |
$\endgroup$
  • $\begingroup$ Thanks for your answer. The number of rounds I suggested was an arbitrary number, I may provide a higher maximum, or even link the two; 384 is 24 rounds, 448 is 28. As for the constant change.. I believe that if the key used is generated using a secure method, and that it provides sufficient entropy, it will introduce the required asymmetry. Of course this is contingent on that strong key, a weak key could seriously compromise the security. I will add a function that performs basic tests on the key. I'll read through the links you posted, thanks.. $\endgroup$ – JGU Nov 11 '14 at 19:57
  • $\begingroup$ "Setting start value of counter with key will cause same block outputs with different keys at some points as counter will change key." Not sure what you mean by that, can you clarify? $\endgroup$ – JGU Nov 11 '14 at 20:21
  • $\begingroup$ @John Adding rounds will of course affect performance. Why do you think 24 is enough/needed for 384-bit key and 28 for 448-bit key? You would have to analyse Salsa20 like Mouha and Preneel did to know how many rounds you need. $\endgroup$ – LightBit Nov 11 '14 at 20:25
  • $\begingroup$ @John Lets say you have key1 = 12 and key2 = 11. Then first block of key1 will be the same as second block of key2. Because counter will increase key. $\endgroup$ – LightBit Nov 11 '14 at 20:29
  • 1
    $\begingroup$ Slide attacks are not applicable to Salsa20 or ChaCha because it does not use round keys. $\endgroup$ – forest Feb 27 '19 at 8:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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