Stream-Cipher Keystream Reuse — the umbrella break behind every reused-keystream challenge

Every additive stream cipher (RC4, ChaCha, AES-CTR/OFB/CFB, an LFSR-based generator) encrypts as c = p ⊕ keystream; the moment the same keystream is reused across two plaintexts, XORing the ciphertexts cancels the keystream entirely — c1 ⊕ c2 = p1 ⊕ p2 — collapsing security to a pure text-recovery puzzle with no key involved at all.

The signal that betrays it

- Multiple ciphertexts produced under the same key and the same IV / nonce / counter start — the classic setup is a service that re-seeds a stream cipher with a fixed key per connection, or a fixed nonce hardcoded in source. - A stream cipher with a key and no nonce parameter visible in the protocol at all — if there's nowhere for freshness to come from, every message under that key shares keystream. - Two (or more) ciphertexts of the same declared length, from the same endpoint, encrypted "too close together" or on a service that clearly doesn't rotate anything between calls. - The confirming test: XOR two ciphertexts together. Real random keystream XORed with real random keystream should look uniformly random. If c_i ⊕ c_j instead shows an English/ASCII-shaped bias (lots of bytes in the printable range, a bias toward 0x20-flipped nibbles), that's not noise — that's p_i ⊕ p_j, and the reuse is confirmed on the spot before you write a line of exploit code.

How to exploit it

1. Detect reuse first, don't assume it. Compare IVs/nonces across captured messages if they're visible; if not, XOR every pair of ciphertexts of matching length and eyeball (or entropy-test) the result for the non-random signature above. 2. Two messages, one guessed word (crib-drag): slide a probable plaintext fragment (crib) across c1 ⊕ c2 at every offset; wherever XOR(x[off:off+len(crib)], crib) comes out all-printable, you've likely found the crib's true position in one message and can read the fragment it exposes in the other. Good starter cribs are function words ("the", "and", "that") or fixed structural strings the protocol is known to use. 3. Many messages (many-time pad): go column-wise across all ciphertexts XORed against each other and exploit that in ASCII, XORing the space character (0x20) into a letter flips its case. Voting per keystream-byte position across many pairwise comparisons converges on the whole keystream, not just fragments — see One-Time-Pad / Many-Time-Pad Reuse — the crib-drag break when a pad is used twice for the full statistical procedure. 4. One known plaintext: if you can pin down even one full plaintext (e.g. a fixed banner, a known header), keystream = c ⊕ p recovers that segment of keystream directly, and you decrypt every other ciphertext sharing that keystream span for free.

```python def xor(a, b): return bytes(x ^ y for x, y in zip(a, b))

def crib_drag(c1, c2, crib): # crib: probable plaintext fragment, as bytes x = xor(c1, c2) for off in range(len(x) - len(crib) + 1): frag = xor(x[off:off + len(crib)], crib) if all(32 <= b < 127 for b in frag): yield off, frag # candidate text revealed in the *other* message at this offset ```

This is the exact mechanism the U.S. Signal Intelligence Service exploited against reused Soviet "one-time" pads in the Venona project — reuse turns a theoretically unbreakable cipher into a language puzzle, no matter how random the underlying key was.

What does NOT work

- Recovering the key. This attack recovers *plaintext*, never the key or the underlying generator state. c1 ⊕ c2 only ever gives you p1 ⊕ p2 — the keystream itself stays unknown unless you separately pin one full plaintext (step 4 above). Don't waste time trying to reverse-engineer the cipher's internals from this; it's the wrong target. - Treating it as a factoring/algebra problem. Unlike the RSA or DH families, there is no modulus, exponent, or group order to exploit here — this is pure XOR algebra plus natural-language redundancy. Bringing lattice or number-theoretic tooling to a keystream-reuse challenge is a category error; the tool you need is a crib-dragger or a frequency vote, not a solver. - Single-message XOR "brute force" without a second ciphertext. With only one ciphertext and no known plaintext or reused keystream to compare against, there is nothing to cancel — this technique needs at least two messages sharing keystream, or one message plus a confidently known plaintext. A single unknown ciphertext under a fresh, unreused keystream is not breakable this way at all. - Assuming any bias in `c1 ⊕ c2` proves reuse. Short ciphertexts or non-English plaintext (binary data, compressed content) can produce ambiguous or misleading XOR output; confirm reuse via the IV/nonce metadata when it's available rather than relying on eyeballing printable bytes alone, especially before committing to a full crib-drag session.

Related

One-Time-Pad / Many-Time-Pad Reuse — the crib-drag break when a pad is used twice CTR Nonce Reuse — when the counter mode keystream repeats Repeating-Key XOR — recovering key length and key from a Vigenère-style stream LFSR State Recovery — when the keystream itself hands you the seed PRNG State Prediction — recovering the internal state of a non-cryptographic generator Block Cipher Modes of Operation — the mode carries the CTF vulnerability, not the primitive