What is the role of IV in stream ciphers? Why is it needed and what is its importance?

Question

I ran into this problem when I read about stream ciphers and did not find a satisfactory answer.

Why is an IV needed in stream ciphers, and what is the importance of using it?

Answer 1

An IV is required for any symmetric cipher if you want to reuse the key. The simple reason is that key reuse would otherwise leak information about the plaintext. In the most basic sense you would get the same ciphertext if a message is repeated. This is easy to see: symmetric ciphers are deterministic and there is no unique input, so the result must be the same - as for any algorithm.

For stream ciphers that generate a key stream which is XOR'ed with the plaintext message the issue is even more pronounced. In that case you get the same issue as a many-time-pad, and it will be easy to retrieve much more information about the two input messages. If enough information is known then the full message could be leaked, even though the key should still be secure.

For most stream ciphers it is enough to supply a nonce (a number-used-once, simply a unique number for that particular key or even just a unique bit string); the IV doesn't need to be random as for some modes of operation such as CBC. As long as a unique nonce is given, the key stream will be indistinguishable from random.

---

Some stream ciphers do not accept an IV. In that case a unique key must be generated. In many cases it is then possible to simply concatenate key and IV as to generate a key stream indistinguishable from random, but if the security properties of the key are suspected to be less than perfect, using a KDF with a salt or Info field that represents the IV to derive a new key for each encryption is a better option.

One of these ciphers is RC4. Of course it is not good advice to use the old RC4 due to many security issues with it. In case of RC4 - which is broken in more than one way - it seems a better idea to use a KDF as described above. It would be even better to avoid using this ancient algorithm altogether; try e.g. Salsa or ChaCha, which does support an IV or rather nonce.

Answer 2

Take a cipher, any cipher, and suppose the key is used for multiple messages.

Suppose that two messages happen to be identical. If the ciphertext depends only on the key and the message, then the ciphertexts for these messages will be identical. This leaks information about the messages. There are scenarios where this doesn't matter, but conversely, there are scenarios where it matters. Therefore, any cipher uses a nonce in addition to the key. In ciphers that use an IV (or something related such as an initial counter value), the IV is this nonce.

The nonce must have at least the property that the sender never performs two encryption operations with the same nonce. (Encrypting distinct messages with the same nonce would leak the fact that the messages are distinct.) Depending on the role that the IV plays in the cipher, there may be additional constraints.

With a stream cipher, the effects of encrypting twice with the same key and without using a nonce are rather devastating. Write $M[i]$ for the $i$th bit of the message and $C[i]$ for the $i$th bit of the ciphertext; then $C[i] = S[i] \oplus M[i]$ where $S$ is the keystream. If $S$ only depends on the key, then an adversary who obtains two ciphertexts $C_1$ and $C_2$ obtains $M_1 \oplus M_2 = C_1 \oplus C_2$. Guessing one bit of one message automatically reveals the bit in the same position in the other message, without having any information about the key.

The remedy is to ensure that the same keystream is never used twice. This can be done by ensuring that the key is only ever used once, or by incorporating a nonce (an IV) in the way the keystream is derived from the key.