A keystream is the generated sequence of bits or bytes XORed with plaintext to produce ciphertext in a stream cipher. Unlike the fixed-length key or seed, it can grow to match the message: both parties initialize the same generator from the shared seed and independently produce the required keystream length. section 4.1.2
Figure 4.4 The difference between the key and the keystream
Distinguishes the fixed-length seed, which initializes a generator once, from its expandable keystream output used for encryption. section 4.1.2
Encryption and decryption use XOR. For each position, combine plaintext with the corresponding keystream value; applying the same keystream again reverses the operation. A 1 GB message therefore needs a 1 GB keystream, but the communicating parties need share only the generator seed rather than a key as long as the message. section 4.1.2 section 4.3.1
Generating bytes with RC4
RC4 runs key scheduling once to initialize a 256-byte S-box, then its pseudorandom generation algorithm mutates that state and emits one keystream byte per iteration. Encryption generates exactly as many bytes as the plaintext and XORs each pair. This contrasts with an LFSR implementation, which emits individual bits and calls its bit generator eight times per plaintext byte. section 4.3.1 section 4.2.1
Figure 4.12 One iteration of PRGA producing a keystream byte (after i and j are already swapped)
Shows one RC4 PRGA iteration selecting a byte from the evolving S-box as keystream output. section 4.3.1
Seeing keystream values can expose the corresponding plaintext positions: known plaintext XORed with ciphertext yields the keystream. A CSPRNG-based design aims to prevent recovered output from revealing its seed or predicting unseen future output. That protection is not automatic for every generator. A single LFSR is fast and hardware-friendly, but its linear output can let an attacker recover its internal state from observed keystream bits and then predict later bits. section 4.1.2 section 4.2
Known-prefix LFSR attack
If intercepted ciphertext begins with the known prefix “ATTACK AT ”, XORing that prefix with the ciphertext recovers its keystream bits. Those bits can be used to clone an LFSR by trying lengths and solving its linear relationships. The cloned generator predicts the remaining keystream, allowing XOR decryption of the unknown timestamp; successful parsing validates the guess. section 4.2.2
Keystream recovery can have different consequences depending on the cipher. Reversing the LFSR example predicts output without necessarily recovering its original key. In the WEP use of RC4, however, statistical biases tied to weak initialization vectors allow repeated packet observations to turn known keystream bytes into guesses for bytes of the preshared key. More packets improve the frequency-based recovery; too few can produce incorrect key bytes. section 4.3 section 4.3.2
Treat keystream handling as a security boundary:
- Use a generator whose output is intended to resist seed recovery and prediction after some output is known. section 4.1.2
- Do not rely on a lone LFSR when its linear output permits state recovery from observed keystream. section 4.2
- Avoid weak-IV RC4/WEP constructions, where biased keystream observations support preshared-key recovery. section 4.3.2

