# Fundamental difference between the constant, key, nonce, and counter bits in Salsa20/ChaCha20 or AES-Encrypt?

The Salsa20 core function takes a 128-bit constant, 256-bit key, 64-bit counter, and 64-bit nonce and produces a 512-bit value. Or more generically, it is a mapping from 512-bit values to 512-bit values.

Is there a reason specific input bits were chosen for specific purposes? For example, if the some of the counter bit positions and key bit positions were swapped, would this result in a weaker cipher? What if we used the constant bits as additional key bits?

What about AES-Encrypt? If we view AES-128-Encrypt as a mapping from 256-bit values to 128-bit values, can we use whichever of the input bits we want for the key and IV input block without weakening it?

Edit: Clarifying my AES question: I wrote IV but I meant input block. (Depending on the mode of operation, the input block might be an IV, plaintext block, counter, etc.)

And now that I think about it, it's clear that the key bits are different from the input block bits. Given the output of AES-Encrypt and the input block, it's difficult to determine the key. However, given the output of AES-Encrypt and the key, it's trivial to determine the input block: just apply AES-Decrypt.

• AES is completely different from Salsa20/ChaCha. The key and IV are fundamentally different in AES.
– forest
Aug 29, 2019 at 9:46
• By the way, I believe this is all explained in the Salsa20 and ChaCha papers. They're not hard to read.
– forest
Aug 29, 2019 at 9:59

Is there a reason specific input bits were chosen for specific purposes? For example, if the some of the counter bit positions and key bit positions were swapped, would this result in a weaker cipher?

No, there would be no real effect on security. The specific positions were chosen primarily to improve SIMD implementation performance. The Salsa20 and ChaCha core functions, ignoring the constant, can be thought of as a $$f : \{0,1\}^{384} \rightarrow \{0,1\}^{512}$$, so the exact locations for the various bits don't really matter as long as it is secure, which it is thought to be. In fact, the IETF variant of ChaCha uses a different nonce and counter size from the original version by Bernstein (96:32 vs 64:64, respectively).

Note that the positions do have some security implications. Section 3.2 of the ChaCha paper explains how the attacker-controlled words were more spread out in Salsa20 and gave an attacker extra flexibility, but made analysis of the cipher easier. ChaCha, on the other hand, keeps all attacker-controlled words (the nonce and counter, regardless of their size as long as they both sum to 128 bits) on the bottom row of the input matrix. However, the effect on security is extremely small for a standard number of rounds.

What if we used the constant bits as additional key bits?

Now that would not be a good idea. The constant is important, although the specific value is somewhat arbitrary. Without the constant, an all null key, nonce, and counter would result in an all null keystream block. In theory, a completely random, uniformly-distributed key could be extended to use the counter bits and it would have a negligible chance of resulting in security issues, but that would violate the security properties of the cipher (after all, you'd have to create restrictions as to what a valid key is!).

What about AES-Encrypt? If we view AES-128-Encrypt as a mapping from 256-bit values to 128-bit values, can we use whichever of the input bits we want for the key and IV without weakening it?

AES is completely different from Salsa20. It is a block cipher, so the IV (which, for most block modes, is nothing more to the cipher itself than an input message) and the key are fundamentally different.

• @SqueamishOssifrage when you say "message number" are you talking about the nonce? Aug 29, 2019 at 22:41
• @KannanGoundan Yes. In the case of ChaCha or Salsa20, it is not safe to use anything substantially different from a message number as the nonce. For XChaCha or XSalsa20, you can safely choose the nonce at random. But it's too small to do that safely for ChaCha and Salsa20. Aug 29, 2019 at 23:34
• @SqueamishOssifrage Thank you for the correction. What is the term for an unkeyed PRF? I have heard "unkeyed PRF" used as interchangeable with "unkeyed hash function", but now I'm not sure if that's correct.
– forest
Aug 30, 2019 at 5:51
• @forest What is the concept you are trying to convey? ‘PRF’ specifically means that the distribution on $f_k\colon A\to B$ is hard to distinguish, when $k$ is uniform random, from the distribution on uniform random $F\colon A\to B$. If there's no distribution on keys or functions then the concept is not relevant. If you're invoking the security conjecture of Salsa20/ChaCha, then splitting the block into key and input and constant as a PRF is crucial because that's what's been studied; without that, the permutation has various symmetries that (e.g.) render it unfit for sponges like Keccak. Aug 30, 2019 at 13:20
• @SqueamishOssifrage A hash is the term I wanted to convey. Sorry for the confusion.
– forest
Aug 30, 2019 at 23:44