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

Question

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.

Answer 1

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.