ChaCha has clear delineations between key, nonce, counter and constants.

What is the reason for not using a XEX-like ($k=0$) approach such that the ChaCha key is 512 bits and all the other things are XOR'ed with the key, and only the key is XOR'ed with the ChaCha permutation output?

ChaCha already has some similarity to Even-Mansour with the way it is constructed, why not go all the way? Currently, it only does partial single key Even-Mansour with partially known key, known plaintext and partially exposed ciphertext.[1]

Attacker doesn't gain any additional control over the input he did not have before, and the security of the cipher when the attacker is passive becomes $2^{512}$.

Are there any downsides?

[1] If ChaCha is an Even-Mansour-like construction then:

  • half of the key is effectively 0
  • constants, counter, nonce are all known, rest of the plaintext is 0
  • $\begingroup$ 256 bits of security is enough againts for all adversaries, classical and quantum. The biggest problem with ChaCha is the short nonce size. To increase the none size XChaCha20 wad developed ; Xchacha20 extends the nonce of ChaCha20 without changing the function of ChaCha20. The aim of Xchacha20 is to extend the 128-bit nonce size of ChaCha20 to 192-bit in order to generate random nonces to use safely in the long-lived keys without the fear of the nonce-collision. $\endgroup$
    – kelalaka
    Commented Oct 8, 2023 at 3:41
  • $\begingroup$ 256 may be enough, but my question is why not have 512. is there any downside? $\endgroup$ Commented Oct 8, 2023 at 4:00
  • $\begingroup$ 256 maybe enough for who, 512 may be enough for who? ChaCha has 512-bit block size, you need to consider this, too, since you will get 768 key size. XEX was started to increase the key size of DES, then with Rogaway's tweak it is used for disk encryption ( well modified to XTS) so people are content with AES-256m, there. So, why do you need 512-bit key size? $\endgroup$
    – kelalaka
    Commented Oct 8, 2023 at 4:39
  • 1
    $\begingroup$ I believe Even-Mansour security is limited to half of block size. Also ChaCha requires constants to break symmetry. $\endgroup$
    – LightBit
    Commented Oct 8, 2023 at 17:18
  • $\begingroup$ constants can be xored into the key, and they are there under the assumption that someone will choose a very stupid symmetric key & nonce. if that occurs you really have bigger problems. $\endgroup$ Commented Oct 8, 2023 at 22:24

1 Answer 1


The obvious downside is there would be $2^{256}$ weak inputs (key-nonce-counter) due to ChaCha requiring constants to break symmetry (see this paper at 3.1 about NORX permutation based on ChaCha) and collisions between key and nonce/counter which are expected in Even-Mansour, but not in ChaCha. It is also unknown if ChaCha permutation is free of differential and linear characteristics with complexity lower than $2^{512}$.

There is little to no upside since Even-Mansour is considered secure up to $2^{n/2}$.

As to why it is not designed to have 512-bit key. It is because it is considered unnecessary.

Using Keccak permutation would be better. It is 1600-bit and has round constants that break symmetries internally. It could provide 800-bit security in Even-Mansour and plenty of nonce/counter bits. I would still recommend concatenating input like ChaCha instead of xoring them together, as it is waste of insane 1600-bit key that looses strength with number of blocks generated.


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.