Why This Matters
Mode choice is the most commonly misunderstood AES decision. ECB mode is still found in production systems in 2026. Choosing the wrong mode can render AES encryption completely ineffective — leaking plaintext structure, enabling bit-flip attacks, or allowing full plaintext recovery through padding oracles.
ECB: The Dangerous Default
AVOIDElectronic Codebook mode encrypts each block independently with the same key. Identical plaintext blocks produce identical ciphertext blocks, leaking the structure of the message. As defined in NIST SP 800-38A, ECB should never be used for multi-block data.
Key (hex)
Ciphertext (hex)
Block Comparison
Same color = identical ciphertext block (structure leaked) Different color = different ciphertext block
ECB Penguin Effect
Original
ECB Encrypted
Why ECB Is Never Appropriate
ECB encrypts each 16-byte block independently. This means repeated plaintext blocks always produce repeated ciphertext blocks. An attacker learns where repetition occurs — destroying confidentiality for structured data like images, database fields, or protocol messages.
Implementation note: WebCrypto does not support ECB natively. This demo implements ECB by encrypting each 16-byte block individually using AES-CBC with a zero IV, which for a single block is equivalent to ECB encryption. This approach is documented honestly — ECB is shown only to demonstrate why it must be avoided.
CBC: The Classic Workhorse
LEGACYCipher Block Chaining mode XORs each plaintext block with the previous ciphertext block before encryption. As defined in NIST SP 800-38A, CBC requires a unique, unpredictable IV for each encryption and provides confidentiality but not integrity.
Key (hex)
IV (hex)
Ciphertext (hex)
Block Chaining Visualization
Vulnerability Demo
CBC Vulnerabilities
IV reuse: Same plaintext + same IV + same key = identical ciphertext. The IV must be unpredictable for each encryption.
Bit-flip attack: Flipping bit i of ciphertext block n flips bit i of plaintext block n+1 — enabling controlled plaintext manipulation without knowing the key.
No integrity: CBC provides confidentiality only. Without a MAC (e.g., HMAC in Encrypt-then-MAC), ciphertext tampering goes undetected. This is why AEAD modes like GCM replaced CBC.
CTR: Stream Mode
ACCEPTABLECounter mode turns AES into a stream cipher by encrypting successive counter values to produce a keystream, then XORing with plaintext. As defined in NIST SP 800-38A, CTR requires a unique nonce/counter combination for every encryption — nonce reuse is catastrophic.
Key (hex)
Counter/Nonce (hex)
Ciphertext 1 (hex)
Counter + Keystream Generation
Nonce Reuse Attack
Nonce Discipline Is Everything
If two messages are encrypted with the same key and nonce, XORing the two ciphertexts cancels out the keystream: C₁ ⊕ C₂ = P₁ ⊕ P₂. An attacker who knows (or guesses) one plaintext can recover the other. CTR is secure only when every (key, nonce) pair is unique.
GCM: Authenticated Encryption
RECOMMENDEDGalois/Counter Mode combines CTR encryption with GHASH authentication. As defined in NIST SP 800-38D, GCM provides both confidentiality and authenticity, including authentication of Additional Authenticated Data (AAD). The nonce must never repeat with the same key.
Key (hex)
Nonce (hex, 12 bytes)
Ciphertext (hex)
Auth Tag (hex)
Tamper Detection
Why GCM Is the Recommended Default
GCM provides authenticated encryption — any modification to the ciphertext, AAD, nonce, or tag causes decryption to fail. This prevents bit-flip attacks, padding oracle attacks, and all forms of ciphertext tampering.
Tag truncation: Per NIST SP 800-38D §5.2.1.2, truncating the authentication tag below 128 bits reduces the effort required for a forgery attack. A t-bit tag provides at most 2−t forgery probability per attempt. Tags shorter than 96 bits are not recommended.
CCM: Constrained Environments
ACCEPTABLECounter with CBC-MAC mode combines CTR encryption with CBC-MAC authentication. Defined in RFC 3610 and NIST SP 800-38C, CCM is a two-pass AEAD mode suitable for constrained environments where code size and complexity matter.
Key (hex)
Nonce (hex)
Ciphertext + Tag (hex)
CCM vs GCM Comparison
When to Use CCM
CCM is specified in RFC 3610 and used in IEEE 802.15.4 (Zigbee), Bluetooth Low Energy, and other constrained protocols. It uses only the AES block cipher — no dedicated hash or GHASH — making it suitable for hardware with minimal gate count.
For general-purpose applications, GCM is preferred due to its single-pass operation and hardware acceleration support (PCLMULQDQ/CLMUL instructions).
Implementation note: WebCrypto does not support CCM. This demo implements CCM from AES block primitives using @noble/ciphers ECB for single-block AES encryption, building CBC-MAC + CTR per RFC 3610.
Padding Oracle Attack
ATTACK DEMOA step-by-step demonstration of a CBC padding oracle attack. The oracle reveals only whether PKCS#7 padding is valid — yet this single bit of information is enough to recover the entire plaintext, one byte at a time.
Target Ciphertext (hex)
Attack Progress
Recovered Plaintext
Oracle Query Log
Why This Attack Works
PKCS#7 padding requires the last n bytes to all equal n. A padding oracle — any system that reveals whether padding is valid — leaks one plaintext byte per ~128 queries on average. Across 16 bytes per block, the entire plaintext is recovered using only ~2,048 oracle queries per block.
Defense: Use authenticated encryption (GCM, CCM, ChaCha20-Poly1305). If CBC is unavoidable, use Encrypt-then-MAC and verify the MAC before attempting decryption — never reveal padding validity.
See also: crypto-lab-shadow-vault for ChaCha20-Poly1305 AEAD.