I'm reading the salsa20 spec (sorry for the newbie question, i'm really a newbie here). Every paragraph ends with : "this operation is invertible", I suppose the whole salsa20 algorithm is.
Every paragraph ends with : "this operation is invertible", I suppose the whole salsa20 algorithm is.
The Salsa20 quarterround, and thus rowround, columnround and doubleround are invertible. However, the whole Salsa20 core is not because the initial state is added to the state after iterating the rounds (cf. page 6 in the spec).
- If I use salsa20 in bloc cipher CTR mode, this property does not seems mandatory to me, am I right?
If the whole cipher core was invertible, then a known plaintext attack would reveal the key. So not being invertible is a requirement, somewhere along the line.
- As such, any cryptographically-robust hash function (one-way only) could be used for CTR encryption?
This is correct. See, for example this question.
- Isn't it easier to design a robust hash than a robust cipher?
Maybe, but block ciphers are usually much faster than a hash function in CTR mode. Hash functions are optimized to consume data, not output it. Stream ciphers, OTOH, are occasionally even faster, like you can see if you compare Salsa20 and AES in software implementations.
The basic building block of salsa20 is a fixed 512 bit permutation. This is similar to a block cipher with a fixed and publicly know key (or a zero bit key if you prefer). Since it has no key input, you can't use it with block cipher modes of operation.
The next step in Salsa20 is a feed-forward by adding the input into the output, turning it into an unkeyed hash function/one-way-function.
If $P(x)$ is a permutation and thus reversible, $P(x)\oplus x$ is one way.
This is the standard way for turning a reversible function into an irreversible one, and is often used to build compression functions.
The input of this 512 bit function gets divided into several parts: A 256 bit key, an 8 byte stream identifier (IV) an 8 byte counter and 16 bytes of fixed padding. Note that the padding is necessary to remove certain symmetries from the raw hash function.
This turns the unkeyed hash into a keyed one, formally a PRF (pseudo random function)
Finally to produce a long output Salsa20 calls the core function with a different counter for each 512 bit block. This is very similar to the CTR mode used with block ciphers.
2) As such, any cryptographically-robust hash function (one-way only) could be used for CTR encryption?
A generalized counter mode can be used with any PRF, which is the formalization of a keyed hash.
Building a PRF from an unkeyed hash is easy in practice and secure for most hashes we use, such as SHA-2 or SHA-3. Theoretically it's tricky and probably needs the random oracle assumption.
1) If I use Salsa20 in block cipher CTR mode, this property does not seems mandatory to me, am I right?
If you interpret Salsa20 as a 512 bit block cipher it's clearly not secure, since it has a zero bit key and undesirable symmetries on top of that. So you can't use it in CTR mode as it's defined for block ciphers.
On the other hand, the Salsa20 function as described in Step 3 above is believed to be a PRF, and Step 4 is a kind of counter mode, so in a way you're always using Salsa20 in CTR mode.
3) Isn't it easier to design a robust hash than a robust cipher?
Pretty much all hashes we use are built from a permutation, keyed (aka block cipher) or unkeyed. The key idea is that the irreversible operation is where collisions happen, so we want only a single one of those and it should be as far as possible from what the attacker controls.
So I don't think it's easier to build a hash than a permutation or block cipher. In some ways it's harder, since we often request collision resistance from hashes, whereas ciphers are generally used with random keys the attacker has no control over.
