Two-Time Pad: How Nonce Reuse Breaks Stream Cipher Encryption

Two-Time Pad Attack

Message length 20 bytes

Live Readouts

Bit-match rate

—

Bytes recovered

—

Keystream status

Same K reused for both messages

Captured Traffic

C1 ⊕ C2 (attacker computes this):
—

True P1 ⊕ P2 (hidden from attacker, shown for verification):
—

How it works

A stream cipher encrypts by XOR-ing plaintext bytes with a pseudorandom keystream K generated from a key and a nonce: C = P ⊕ K. XOR is its own inverse, so the same K decrypts it. That is safe only if K is never reused.

C1 = P1 ⊕ K
C2 = P2 ⊕ K
C1 ⊕ C2 = (P1 ⊕ K) ⊕ (P2 ⊕ K) = P1 ⊕ P2 ⊕ (K ⊕ K) = P1 ⊕ P2

When the same keystream K encrypts two different messages, K cancels out completely when you XOR the two ciphertexts — an eavesdropper who never learns K still recovers P1 ⊕ P2 directly from traffic on the wire. In practice, "crib-dragging" a guessed word through that XOR (spaces, common letters, sentence structure) peels out both plaintexts almost entirely, without ever breaking the cipher itself.

Nonce reuse toggle — forces K2 = K1 (vulnerable) or draws an independent K2 (safe). This is exactly the nonce/IV field in real protocols.
New messages — samples two fresh plaintexts and fresh keystream(s).
Message length — how many bytes are compared.
Attack & verify — computes C1 ⊕ C2 (all an attacker ever needs) and checks it bit-for-bit against the true P1 ⊕ P2, which only the sender/receiver actually know.

Real-world relevance: this exact flaw broke Microsoft's original MS-PPTP VPN handshake, the WEP Wi-Fi protocol's RC4 usage, and has recurred whenever an AES-CTR or ChaCha20 nonce got reused (e.g. cryptocurrency wallet bugs, misconfigured disk encryption). It is why TLS, WireGuard and modern AEAD ciphers derive a fresh, unique nonce for every single message.

Ciphertext C1 (P1 ⊕ K1) Ciphertext C2 (P2 ⊕ K2) Attacker's C1 ⊕ C2 True P1 ⊕ P2 (reference) /match / mismatch

⚠ Couldn't load the 3D engineThree.js failed to load from the CDN. Check your connection and reload.