Cryptography / Failure Analysis

Symmetric Mode Attacks: ECB, CBC & CTR

Evaluating symmetric block cipher modes requires understanding their specific cryptanalytic failure modes. Unauthenticated cipher modes fail in distinct ways: Electronic Codebook (ECB) leaks structural patterns, Cipher Block Chaining (CBC) is vulnerable to bit-flipping and padding oracle attacks, and Counter (CTR) mode collapses into a two-time pad when nonces repeat under the same key.

Attack Summary Matrix

1. ECB Mode: Structural Pattern Leakage

In ECB (Electronic Codebook) mode, every 16-byte plaintext block P_i is encrypted independently using key K:

C_i = E_K(P_i)

When identical plaintext blocks occur in input data, identical ciphertext blocks are emitted.

AES-128-ECB block pattern leakage: four identical 16-byte plaintext blocks yield identical 16-byte hex ciphertext outputs (ecb_leak.py)

Client-Side Executable ECB Cryptanalysis Playground

Chosen-Plaintext & Dictionary Cryptanalysis Attack (ECB Codebook Exploitation)

When a server encrypts data using AES-ECB mode and also exposes an Encryption Oracle (such as a web portal or API endpoint that encrypts attacker-chosen input under the same key K), an adversary can build a Codebook / Dictionary Table mapping candidate plaintexts to their resulting ciphertext blocks — without ever learning K itself.

This is a known-plaintext / chosen-plaintext matching technique, not a general decryption method: a target block is only recovered when the adversary has already guessed its exact 16-byte plaintext and submitted that guess to the oracle. Once a generated ciphertext block matches a block in the stolen target file, that specific block is decrypted by lookup; a block whose true plaintext was never guessed stays opaque no matter how many other candidates are queried:

Because this attack succeeds purely on ciphertext equality, it never decrypts a block outright — it only confirms that a block’s plaintext equals whatever the attacker already guessed and queried through the oracle. A target block encoding an unguessable value (a random session token, for example) will never appear in the codebook and therefore never gets recovered by this method.

2. CBC Mode: Bit-Flipping Malleability & Padding Oracle Attacks

In CBC (Cipher Block Chaining) mode, plaintext block P_i is XORed with previous ciphertext block C_i-1 before encryption:

P_i = D_K(C_i) ⊕ C_i-1

Because C_i-1 is XORed directly into decrypted plaintext P_i, altering byte k of C_i-1 changes byte k of P_i by the exact same bitmask, while scrambling block P_i-1 into unrecoverable noise.

CBC bit-flipping mechanics: altering ciphertext block 1 flips targeted bits in block 2

Client-Side Executable CBC Bit-Flipping Privilege Escalation Playground

Because unauthenticated CBC mode lacks an authentication tag (AEAD), decryption succeeds without raising an integrity exception — the tampered plaintext is accepted as valid. Granting unauthorized administrative privileges is this simulator’s chosen scenario, not a property CBC inherently grants; the general lesson is that unauthenticated CBC lets an attacker flip bits in decrypted plaintext undetected, and what that plaintext controls in a real system (an admin flag, a price, a redirect URL) determines the actual impact.

Padding Oracle Attack Mechanics (Vaudenay’s Attack)

A padding oracle is any endpoint that decrypts CBC ciphertext and leaks — via a distinct error message, HTTP status code, or timing difference — whether the resulting PKCS#7 padding was valid. PKCS#7 padding fills the final block so its last n bytes each equal the value n (one padding byte of 0x01, or two bytes of 0x02 0x02, and so on).

Because decryption computes P_i = D_K(C_i) ⊕ C_i-1, an attacker who controls C_i-1 can blindly flip any bit of P_i by flipping the corresponding bit of C_i-1 — enough for the bit-flipping attack above — but that alone doesn’t let the attacker set P_i to a chosen value, since D_K(C_i) (the intermediate value I_i, before the XOR) is still unknown to them. The padding oracle is what closes that gap: by observing which byte guesses produce valid padding, the attacker recovers I_i one byte at a time, and only once a given byte of I_i is known can they XOR it against any chosen plaintext byte to compute the C_i-1 byte that produces it. The attack recovers a target block C_i working backward from its last byte:

1. Replace the last byte of C_i-1 with each of the 256 possible values and resend the (unmodified) C_i to the oracle.
2. The guess that yields a valid-padding response reveals the decryption engine’s intermediate value: I_i[15] = guessed_byte ⊕ 0x01 (a single 0x01 pad byte is the simplest valid case).
3. XOR I_i[15] with the original C_i-1[15] to recover the real plaintext byte P_i[15].
4. Fix byte 15 so it forces padding 0x02 0x02, then brute-force byte 14 the same way, and continue leftward through the block.

Each byte costs at most 256 oracle queries, so a full 16-byte block falls in roughly 4,096 requests — without ever touching K. This is Vaudenay’s 2002 CBC-padding attack, later automated against real deployments by tools such as PadBuster. The fix is to never let padding validity leak as a distinguishable signal: return a generic error for both MAC and padding failures, keep error handling constant-time, or (preferably) verify a MAC over the ciphertext before attempting decryption (Encrypt-then-MAC), so a tampered ciphertext never reaches the padding check at all.

Encrypt-then-MAC: A Concise Correctness Checklist

If you’re not using a native AEAD construction and are instead composing a cipher with a separate MAC by hand (legacy systems, protocols that predate widespread AEAD support), get these four things right — getting any one wrong reopens some version of the padding-oracle or bit-flipping attacks above:

1. Use separate keys for encryption and authentication. Deriving both from the same key (or reusing one key for both roles) risks interactions between the two uses that neither primitive’s individual security proof accounts for — derive two independent keys from a master secret via a KDF (see Key Exchange & Key Derivation).
2. Authenticate the ciphertext, not the plaintext — this is what “Encrypt-then-MAC” means, as opposed to MAC-then-Encrypt or MAC-and-Encrypt (encrypting and MACing the plaintext independently). Authenticating post-encryption output is what lets the verifier reject a tampered ciphertext before ever running it through the decryption/padding-removal logic that the Vaudenay attack above exploits.
3. Include the IV/nonce and any associated metadata in what’s authenticated, not just the ciphertext bytes — an attacker who can swap the IV while leaving the ciphertext and tag untouched can still manipulate the first decrypted block in CBC-style modes if the IV itself isn’t covered by the MAC.
4. Verify the MAC before parsing or decrypting anything, and reject on any mismatch with a generic error, in constant time, before any padding-removal or content-parsing logic runs. Checking the MAC only after decrypting (or only after inspecting the padding) is precisely the ordering mistake that makes the padding-oracle attack above possible.

3. CTR Mode: Nonce Reuse Two-Time Pad Attack

In CTR (Counter) mode, AES operates as a stream cipher, encrypting a counter value to generate a pseudo-random keystream KS:

C₁ ⊕ C₂ = (P₁ ⊕ KS) ⊕ (P₂ ⊕ KS) = P₁ ⊕ P₂

If a nonce is reused under the same key, the exact same keystream KS is generated (KS₁ = KS₂). XORing two ciphertexts together eliminates the keystream and secret key entirely, leaving the XOR sum of the two plaintexts (P₁ ⊕ P₂).

CTR nonce-reuse two-time pad: XORing ciphertexts C1 and C2 reveals P1 XOR P2

Client-Side Executable CTR Nonce Reuse Playground

Primary references

• NIST SP 800-38A: Recommendation for Block Cipher Modes of Operation — NIST CSRC SP 800-38A
• RFC 8452: AES-GCM-SIV: Nonce-Misuse-Resistant Authenticated Encryption — RFC 8452 (IRTF/CFRG Informational)
• OWASP WSTG: Testing for Padding Oracle (Vaudenay’s CBC padding attack) — OWASP Web Security Testing Guide