🐧 ECB Penguin — Interactive AES Encryption Demo
Why Electronic Codebook (ECB) mode encryption is fundamentally broken — visualized by encrypting Linux Tux with AES-ECB vs AES-GCM
⚠️ Why ECB Leaks Information
AES-ECB (Electronic Codebook) divides the data into fixed 16-byte blocks
and encrypts each one independently with the same key.
This means identical plaintext blocks always produce identical ciphertext blocks.
Tux's large, flat-colored regions (black body, white belly, sky background) each contain
many consecutive identical 16-byte chunks — all of which encrypt to the same ciphertext value.
The spatial structure of the image is perfectly preserved in the output.
AES-GCM (Galois/Counter Mode) uses a random 96-bit nonce per message
combined with an incrementing counter. Each block gets a unique keystream regardless of plaintext,
so even identical bytes encrypt to entirely different values. The result is computationally
indistinguishable from random noise. GCM also adds a 128-bit authentication tag,
ensuring ciphertext integrity.
The ECB penguin visual proof originated in a cryptography presentation (the original presenter is unknown) and was recreated for Wikipedia by user Lunkwill in January 2004. It was later investigated and enhanced by Filippo Valsorda in 2013. It remains one of cryptography's most famous visual proofs that semantic security requires more than just a secret key.
One AES block = 16 bytes = 4 consecutive pixels. Each pixel is 4 bytes: R, G, B, A. Hover a pixel to inspect its bytes.
Your passphrase is hashed with SHA-256, then the first 16 (or 32) bytes become the AES key. Click Step to walk through it.
Two identical plaintext blocks go into each mode. Click Step to watch what comes out.
The encryption mode your product uses determines its security grade. Here's how the industry evolved from broken to battle-tested.
ECB — Never Used in Any Internet Protocol
ECB is so fundamentally broken that no version of SSL or TLS has ever used it. The protocol designers skipped it entirely. Qualys SSL Labs doesn't even test for ECB — there's nothing to test.
NIST IR 8459 (2024) proposes formally retiring ECB as a confidentiality mode. OWASP states plainly: "ECB should not be used."
If a product encrypts data with ECB mode, it has a fundamental design flaw — not a configuration issue.
CBC — Better, But Vulnerable to Padding Attacks
CBC mode chains blocks together, hiding the patterns that ECB leaks. But it introduced a new weakness: padding verification.
After decryption, the receiver checks if the PKCS#7 padding is valid — the last N bytes should all equal N. If the server responds differently to "bad padding" vs "bad data" — even through timing differences as small as microseconds — an attacker can flip ciphertext bits and observe the response to deduce the plaintext byte by byte, without ever knowing the key.
Think of it like a lock that says "almost right" when you guess wrong — an attacker uses those hints to find the combination.
Products using TLS 1.0–1.2 with CBC cipher suites should be assessed for padding oracle mitigations.
The Kill Chain: Four Attacks That Ended CBC
Each attack proved CBC's padding verification is an inherent liability — patching one variant doesn't prevent the next.
GCM — The Modern Standard
TLS 1.3 (2018) eliminated CBC entirely, requiring only AEAD modes: GCM and ChaCha20-Poly1305. Authentication and encryption are inseparable — there is no padding to attack.
Qualys SSL Labs requires GCM/AEAD cipher suites for an A+ grade. Without them, your grade is capped. Without TLS 1.3, you're capped at A-.
GCM doesn't just keep secrets — it detects if anyone tampered with the data. The authentication tag is a cryptographic proof of integrity that fails loudly on any modification.
When evaluating products, verify they support TLS 1.3 with GCM cipher suites. Check with ssllabs.com/ssltest.