4
$\begingroup$

Can one extend the ChaCha and Salsa20 nonces by XORing the extra nonce bits with the key?

My reasoning is as follows: the Rumba compression function allows attackers to supply any 48-byte input to the core, and HS1-SIV (a CAESAR 2nd round candidate) explicitly assumes and requires that ChaCha20 be secure in the related-key model. As the HS1-SIV authors point out, this IS secure if the ChaCha and Salsa cores are ideal $48B\rightarrow 64B$ PRFs (they XOR a MAC with the key).

$\endgroup$
  • 3
    $\begingroup$ Never ever use the key other than for the operation it is intended for. I'm not sure if you can call this rule one of crypto, but it should rank very high. Besides the fact that security proofs are void if you reuse keys, you may also run into problems if you e.g. use hardware encryption (where the key bytes are simply not exposed). If you must, derive a session key and additional nonce using a KBKDF such as HKDF or one of the NIST SP800-108 ones. $\endgroup$ – Maarten Bodewes Mar 24 '16 at 10:07
  • $\begingroup$ @MaartenBodewes HS1-SIV does exactly what I describe. $\endgroup$ – Demi Mar 24 '16 at 14:52
  • $\begingroup$ @MaartenBodewes ChaCha20 is just a hash core used in counter mode, and with the key, nonce, and block counter all simply inputs to thd PRF. $\endgroup$ – Demi Mar 24 '16 at 18:17
  • $\begingroup$ Note that the Salsa core is actually $64B\rightarrow 64B$, because 16 bytes in the "input" are a constant. $\endgroup$ – forest Mar 12 '18 at 4:18
6
$\begingroup$

Maybe. But your scheme hasn't been vetted by the community for its impact.

Better to use XSalsa20 or the related XChaCha20 as recommended by Bernstein himself: http://cr.yp.to/snuffle/xsalsa-20110204.pdf

In my opinion it was a fairly major faux pas that DJB originally chose short 64-bit nonces for Salsa20 and ChaCha20, especially given all the nonce-misuse attacks in the past. Storing a no-chance-to-repeat counter is actually really hard in practice. He then went on to make a "idiot-proof" crypto library that requires a user-supplied nonce for every "simple" box function, and yet doesn't include the nonce in the authenticated cipher text output.

$\endgroup$
  • $\begingroup$ Doesn't HS1-SIV do exactly this? $\endgroup$ – Demi May 4 '16 at 0:17
  • 2
    $\begingroup$ XSalsa20 definitely does not simply XOR extra nonce bytes with the key. I have not read the HS1-SIV paper, but consider that the XSalsa20 paper provides a formal security reduction to the security of Salsa20. Salsa20 actually won a cipher competition; HS1-SIV is only a candidate. $\endgroup$ – rmalayter May 4 '16 at 2:22
5
$\begingroup$

Can one extend the ChaCha and Salsa20 nonces by XORing the extra nonce bits with the key?

One can, but one probably should not.

Security against related-key attacks is not claimed for either (Salsa20 security pdf):

The standard solutions to all the standard cryptographic problems—encryption, authentication, etc.—are protocols that do not allow related-key attacks on the underlying primitives. I see no evidence that we can save time by violating this condition. The reader might guess that Salsa20 is highly resistant to related-key attacks; but I simply don’t care.

The XSalsa20 cipher, or an equivalent construction from ChaCha20, is a way to extend the nonce that has a security proof (pdf), so it is the one that I would recommend.

$\endgroup$

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.