Cryptographic Mode Visualizer

What Is a Cryptographic Mode of Operation

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.

How Block Cipher Modes Work

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.

Visual Differences Between Modes

This tool visualizes how each mode processes plaintext blocks. The key differences to observe:

• ECB encrypts each block independently — identical plaintext blocks produce identical ciphertext blocks, visibly leaking patterns (the famous "ECB penguin" demonstration)
• CBC chains each block to the previous ciphertext block via XOR, so identical plaintext blocks produce different ciphertext — but encryption cannot be parallelized
• CTR converts AES into a stream cipher by encrypting sequential counter values and XORing with plaintext — fully parallelizable in both directions
• GCM extends CTR with a Galois field multiplication step that authenticates both the ciphertext and any additional unencrypted data (like packet headers)

Common Use Cases

• Learning cryptography: Visualize why ECB mode leaks information and why CBC/CTR/GCM modes do not
• Security architecture decisions: Choose the right mode based on performance requirements, parallelization needs, and whether authentication is required
• Code review: Verify that application code uses appropriate modes — flag ECB usage as a critical vulnerability
• Compliance documentation: Explain to auditors why your implementation uses GCM over CBC and reference NIST SP 800-38D

Best Practices

1. Default to AES-GCM — For most applications, GCM provides the best combination of performance, parallelism, and built-in authentication.
2. Never use ECB for structured data — ECB is only safe for encrypting single blocks (like individual keys). For any multi-block data, it leaks patterns.
3. Never reuse nonces in GCM — GCM nonce reuse is catastrophic: it reveals the authentication key and enables plaintext recovery. Use a counter or random 96-bit nonce with collision probability tracking.
4. Use CTR+HMAC if GCM is unavailable — Encrypt-then-MAC using CTR mode and HMAC-SHA256 provides equivalent security to GCM when AEAD is not available in your library.
5. Understand IV requirements — CBC requires unpredictable IVs (use CSPRNG). CTR/GCM require unique nonces (counters are fine). Mixing these requirements causes vulnerabilities.