A known-plaintext attack starts with matching plaintext and ciphertext and uses that pair to infer secret encryption material. With XOR encryption, plaintext ⊕ key = ciphertext, so rearranging the same operation gives key = ciphertext ⊕ plaintext. A guessed or predictable message prefix can therefore expose the corresponding key or keystream bytes. section 4.1.2 section 4.4
Equation 4.2
\[\text{Key} = \text{Ciphertext} \oplus \text{Plaintext} \label{equation:encrypt-xor-rearranged}\]XOR cancels itself: combining a ciphertext byte with its known plaintext byte recovers the key material used at that position. section 4.1.2
Known plaintext need not mean that an entire message is visible. Common structure can be enough: an eavesdropper who expects a greeting such as “Hello” can XOR that guessed prefix with the intercepted ciphertext and recover the initial key bytes. The result is especially damaging when key material is reused or generated by a reversible, predictable stream mechanism. section 4.1.2 section 4.4
Against a linear feedback shift register (LFSR) stream cipher, the attack can proceed as follows:
- Obtain ciphertext and identify an initial plaintext prefix that is known or strongly predictable. section 4.2 section 4.2.2
- XOR each known plaintext byte with its matching ciphertext byte to recover observed keystream bytes, then expand those bytes into bits. section 4.2.2
- Use the observed bits and the LFSR's linear recurrence to solve for a clone's feedback taps and internal state; try candidate register lengths when the length is unknown. section 4.2 section 4.2.2
- Run the cloned LFSR forward to predict future keystream bits, XOR them with the remaining ciphertext, and validate plausible plaintext. section 4.2 section 4.2.2
Recovering an LFSR-encrypted timestamp
Suppose an intercepted message begins with “ATTACK AT ” followed by an unknown timestamp. XORing the known prefix with the first ciphertext bytes yields keystream bits. A recovery routine tests LFSR lengths, builds a matrix from observed bits, and accepts a cloned LFSR when decrypting the remainder produces a parseable timestamp. The recovered clone then reveals the previously unknown portion of the message. section 4.2.2 section 4.2
The failure is not that XOR cannot encrypt; a one-time pad XORs a truly random key as long as the message and uses a new key for every message. That construction is impractical at scale because the equally long key must be generated and transported securely. Reusing a key also creates a related exposure: XORing two ciphertexts removes the key and leaves the XOR of their plaintexts. section 4.1.2 section 4.4
Treat predictable plaintext as attacker input when designing stream encryption. Avoid direct XOR with reused key material, and do not rely on a standalone LFSR where linear output can be reverse-engineered. More elaborate LFSR combinations increase linear complexity, but the practical goal remains preventing an attacker from turning observed plaintext-ciphertext pairs into a reusable keystream model. section 4.2 section 4.4
