See why ECB mode leaks image patterns and CBC does not. Interactive side-by-side view of block cipher modes, plus an ECB, CBC, CTR and GCM comparison.
This visualizer encrypts a test image twice, side by side: once with a scheme that behaves like ECB and once with a scheme that behaves like CBC. The ECB result still shows the picture. The CBC result is noise. Nothing about the key is weaker in the first case — the difference is purely the mode of operation, and this is the single clearest demonstration in cryptography that a strong cipher used the wrong way provides almost no confidentiality at all.
The tool is educational. It is built for students, security engineers explaining a finding to a developer, and anyone who has read “never use ECB” and wants to understand why rather than take it on faith. It uses simplified per-pixel transforms that reproduce the structural behaviour of each mode; it is not an AES implementation and is not intended for encrypting real data.
The image that made this problem famous is Tux, the Linux penguin, encrypted in ECB mode. Anyone seeing the result immediately understands the flaw without knowing any cryptography: the ciphertext is unmistakably still a penguin, in psychedelic colours. It has been used in textbooks and talks for decades because it needs no explanation.
The mechanism is simple. A block cipher such as AES transforms a fixed-size block — 16 bytes for AES — into another block of the same size. Electronic Codebook (ECB) mode splits the plaintext into blocks and encrypts each one independently with the same key. That makes it deterministic: the same plaintext block always produces the same ciphertext block. An image is full of repetition — a white background is thousands of identical blocks — so every one of those becomes the same ciphertext block, and the structure of the image survives encryption perfectly.
This is not a picture-specific problem. Any structured data leaks the same way. Encrypt a database column of country codes with ECB and the ciphertext still tells you which rows share a country. Encrypt a fixed-format record with ECB and an attacker can identify, count and reorder records without ever recovering the key.
Cipher Block Chaining (CBC) makes each block depend on everything before it. Before encrypting a block, it XORs the plaintext block with the previous block’s ciphertext. The first block has no predecessor, so it is XORed with a random initialization vector instead:
C₁ = Eₖ(P₁ ⊕ IV)
Cₖ = Eₖ(Pₖ ⊕ Cₖ₋₁) for every subsequent block
Two consequences follow. First, identical plaintext blocks no longer produce identical ciphertext, because each is XORed with a different preceding ciphertext block — so patterns disappear and the penguin becomes noise. Second, encrypting the same message twice with the same key but a different IV yields completely different ciphertext, which is why the IV slider transforms the CBC panel and leaves the ECB panel untouched.
The IV must be unpredictable and must never be reused with the same key, but it is not a secret — it is normally transmitted or stored alongside the ciphertext in the clear. A fixed or predictable IV reintroduces exactly the leakage CBC exists to prevent.
CBC has costs. Encryption is inherently sequential, since each block needs the previous ciphertext, so it cannot be parallelised (decryption can be). A single corrupted ciphertext block damages two plaintext blocks on decryption. And crucially, CBC provides confidentiality only — it does nothing to detect tampering, which is the root of a long history of padding-oracle attacks against systems that decrypted CBC data without authenticating it first.
| Mode | Full name | Parallelisable | Error propagation | Hides patterns | Typical use |
|---|---|---|---|---|---|
| ECB | Electronic Codebook | Encrypt & decrypt | Single block only | No | Never use for data |
| CBC | Cipher Block Chaining | Decrypt only | Two blocks | Yes | Disk encryption, legacy TLS |
| CFB | Cipher Feedback | Decrypt only | Two blocks plus bits | Yes | Stream-like encryption |
| OFB | Output Feedback | Neither | Single bit | Yes | Satellite links, noisy channels |
| CTR | Counter | Encrypt & decrypt | Single block | Yes | High-performance, AES-NI |
| GCM | Galois/Counter Mode | Encrypt & decrypt | Single block plus auth failure | Yes | TLS 1.3, IPsec — recommended |
The practical answer for new work is GCM, or another authenticated mode such as ChaCha20-Poly1305. Authenticated encryption gives you confidentiality and integrity in one operation: modified ciphertext fails authentication and is rejected rather than decrypting into plausible-looking garbage. That closes the entire class of attacks that plagued unauthenticated CBC deployments. CTR mode is fast and parallel but, like CBC, is unauthenticated on its own — GCM is essentially CTR with an authentication tag bolted on properly.
One warning that applies to CTR and GCM: the counter or nonce must never repeat under the same key. Nonce reuse in GCM is catastrophic — it leaks the XOR of the two plaintexts and can expose the authentication key itself.
The visualizer uses simplified per-pixel operations chosen to reproduce each mode’s structural behaviour visibly and instantly in a browser. It is a teaching model, not AES, and the outputs are not cryptographically secure. Use it to understand and to explain; use a vetted library for anything real.
To work with actual encryption, try the AES encryption tool. For the asymmetric half of the picture, see public key concepts explained visually and the RSA playground. To see which modes real servers negotiate, look up a suite in the cipher suite reference.
Because it is deterministic. Identical plaintext blocks encrypt to identical ciphertext blocks under the same key, so any repetition or structure in the data survives encryption. With images the leak is visible; with structured records it is just as real but less obvious.
An image of Tux the Linux penguin encrypted in ECB mode, in which the penguin remains clearly recognisable. It is the standard illustration that a strong cipher in the wrong mode provides very little confidentiality.
In CBC it is XORed with the first plaintext block so that encrypting the same message twice with the same key yields different ciphertext. It must be unpredictable and never reused with a given key, but it does not need to be secret. ECB ignores it entirely, which is exactly what the IV slider demonstrates.
GCM, or another authenticated encryption mode such as ChaCha20-Poly1305. They provide integrity as well as confidentiality, so tampered ciphertext is rejected rather than silently decrypted.
It is not broken as a confidentiality primitive, and it remains common in disk encryption and legacy protocols. But it offers no integrity protection, and systems that decrypt CBC data without first authenticating it have a long history of padding-oracle vulnerabilities. Prefer an authenticated mode for new designs.
No. It applies simplified per-pixel transforms that reproduce the structural behaviour of ECB and CBC so the difference is visible immediately. It is a teaching model, not a cryptographic implementation.
The tool ships four built-in test images chosen to expose the flaw clearly. That is the point of the exercise — large flat areas and repeated patterns are exactly what ECB fails to hide.
No. The visualization is generated in your browser on a canvas. Nothing is transmitted.
A cryptographic mode of operation defines how a block cipher (like AES) processes data larger than a single block. Since AES encrypts exactly 128 bits at a time, a mode of operation specifies how to handle messages of arbitrary length — how blocks relate to each other, whether encryption can be parallelized, and whether the mode provides authentication in addition to confidentiality.
Choosing the right mode is as important as choosing the right cipher. A strong cipher like AES can be rendered insecure by a poorly chosen mode, and the wrong mode can introduce vulnerabilities even when the underlying algorithm is sound.
All modes take a block cipher, a key, and (usually) an initialization vector (IV) or nonce as inputs. They differ in how they chain blocks together:
| Mode | Full Name | Type | Parallel Encrypt | Parallel Decrypt | Authentication |
|---|---|---|---|---|---|
| ECB | Electronic Codebook | Block | Yes | Yes | No |
| CBC | Cipher Block Chaining | Block | No | Yes | No |
| CTR | Counter | Stream | Yes | Yes | No |
| GCM | Galois/Counter Mode | Stream | Yes | Yes | Yes (AEAD) |
| CCM | Counter with CBC-MAC | Stream | No | No | Yes (AEAD) |
| CFB | Cipher Feedback | Stream | No | Yes | No |
| OFB | Output Feedback | Stream | No | No | No |
AEAD (Authenticated Encryption with Associated Data) modes like GCM and CCM provide both confidentiality and integrity in a single operation, eliminating the need for a separate HMAC.
This tool visualizes how each mode processes plaintext blocks. The key differences to observe:
ECB (Electronic Codebook) encrypts each block independently with the same key. Identical plaintext blocks produce identical ciphertext blocks, revealing patterns in the original data. The classic "ECB penguin" demonstration shows that an encrypted image in ECB mode still reveals the shape of the original image.
CBC (Cipher Block Chaining) XORs each plaintext block with the previous ciphertext block before encryption. This means identical plaintext blocks produce different ciphertext blocks, hiding patterns. An Initialization Vector (IV) is used for the first block. Changing the IV produces completely different ciphertext for the same plaintext.
ECB encrypts blocks independently (insecure). CBC chains blocks together. CFB converts a block cipher into a stream cipher. OFB generates a keystream independent of plaintext. CTR uses a counter for parallelizable encryption. GCM adds authentication to CTR mode for authenticated encryption. Each has different performance and security tradeoffs.
For most applications, use GCM (Galois/Counter Mode) as it provides both confidentiality and authentication with good performance. Use CBC when GCM is not available. Never use ECB for anything beyond single-block encryption. CTR is good for parallelized encryption. This is covered in CISSP Domain 3.
An IV is a random or unique value used with the encryption key to ensure that the same plaintext encrypts to different ciphertext each time. IVs must be unpredictable (CBC) or unique (CTR/GCM) but do not need to be secret. Reusing IVs with the same key can compromise security, especially in CTR and GCM modes.
Encrypt and decrypt text using AES encryption
Generate MD5, SHA-1, SHA-256, and SHA-512 hashes from text or files. HMAC support, multiple output formats, 100% client-side.
Free Shannon entropy calculator for malware analysis. Detect packed, encrypted, or obfuscated binaries with entropy visualization, byte distribution analysis, and section-by-section scanning.