Stream ciphers are algorithms which encrypt data one bit at a time. This means that the plaintext message can be any size, and the algorithm will generate a ciphertext of equal length. It works by generating a ‘keystream’ which is XORed with the plaintext to output the resulting ciphertext. Both parties must use the same secret key to seed the algorithm.
Stream Cipher Examples
- A5/1 – used in GSM mobile networks
- E0 – used in Bluetooth
- RC4 (Rivest Cipher 4) – can be used in WEP, WPA, TLS, RDP, SSH
- ChaCha20 – used in TLS and OpenSSH
All three above ciphers have known vulnerabilities. For example, RC4 is now prohibited for use in TLS due to the weaknesses which have been found.
Stream Cipher IVs
Stream ciphers rely on a secret key to initialise the keystream. If this initial key is ever repeated, then the system is undermined as the entire keystream is also repeated. If an attacker can collect many different samples of traffic encrypted with the same keystream then they may be able to attack it.
Unfortunately sharing that secret key can be difficult. Therefore, instead of generating a new key each time, we can use an initialisation vector. This IV is combined with the key and shared openly between both sides each time we encrypt/decrypt, or it is changed regularly in a known way. An attacker can know the IV without compromising the integrity of the system – they still don’t know the secret portion of the key. However, if the IV ever repeats then the crypt is undermined as detailed above. When the unique IV is combined with the secret key, we are each time uniquely initialising the system (due to the unique IV) and one which is unknown by an attacker (they don’t know the secret).
When we run out of unique values for the IV, we must generate a new secret key.
Choosing an IV
Having a long IV means that it will be longer before we’ve exhausted all possible IV values. The IV may be incremented sequentially or chosen randomly. However, there are potential weaknesses with both options.