AES Encryption Modes Explained: CBC vs ECB vs CTR vs CFB vs OFB

Why Choosing the Right Mode Matters More Than Choosing the Right Algorithm

AES itself is a block cipher: it can only encrypt a fixed-length (128-bit) block of data at a time. When you need to encrypt data of arbitrary length, you must decide how to "chain" those blocks together — that is exactly what a Mode of Operation solves.

The same AES-256 key used with the wrong mode can catastrophically undermine security. In the 2013 Adobe data breach, the password vault was encrypted using ECB — the weakest possible mode — allowing attackers to infer which users shared identical passwords directly from the ciphertext patterns, without ever recovering the key.

This article compares the five most common AES modes — ECB, CBC, CFB, OFB, and CTR — so you can make the right choice for your project.

Quick Comparison

*CTR uses a Nonce (number used once) instead of a traditional IV — functionally the same concept.

ECB: Simplest, and Most Dangerous

ECB (Electronic Codebook) is the most naive implementation: split the plaintext into equal-sized blocks and encrypt each one independently.

Fatal flaw: Identical plaintext blocks always produce identical ciphertext blocks.

This means the ciphertext preserves structural information from the original data. The classic demonstration is encrypting a Linux Tux penguin image with ECB — the encrypted image still clearly shows the penguin's outline, because blocks of the same color pixels encrypt to exactly the same output.

Plaintext Block A → Ciphertext Block X
Plaintext Block A → Ciphertext Block X  ← Identical! Attackers can infer patterns.
Plaintext Block B → Ciphertext Block Y

Conclusion: ECB should never be used in any real-world scenario. It exists in tools only for compatibility with rare legacy systems.

CBC: Most Widely Used, the Classic Choice

CBC (Cipher Block Chaining) is the most widely deployed mode. Its core idea: before encrypting each block, XOR it with the previous ciphertext block. Since the first block has no predecessor, it requires an Initialization Vector (IV).

Plaintext Block 1 XOR IV → Encrypt → Ciphertext Block 1
Plaintext Block 2 XOR Ciphertext Block 1 → Encrypt → Ciphertext Block 2
Plaintext Block 3 XOR Ciphertext Block 2 → Encrypt → Ciphertext Block 3

Advantages:

• Identical plaintext blocks produce completely different ciphertext due to XOR chaining
• Ciphertext has no detectable patterns — strong security
• Broadly compatible: OpenSSL and encryption libraries in all major languages support it by default

Disadvantages:

• Encryption cannot be parallelized (each block depends on the previous result)
• Decryption can be parallelized
• Requires correct padding handling — Padding Oracle attacks are its primary threat

Use cases: File encryption, database field encryption, API payload encryption. When interacting with OpenSSL's enc command, CBC is the default mode.

💡 You can try CBC mode hands-on with the AES Online Encrypt & Decrypt Tool on toolshu.com. Its "Passphrase Mode" is fully compatible with openssl enc -aes-256-cbc.

CFB: Streaming Encryption for Real-Time Data

CFB (Cipher Feedback) turns a block cipher into a stream cipher. Instead of directly encrypting the plaintext block, it encrypts the previous ciphertext block (or the IV), then XORs the result with the plaintext.

Encrypt(IV) XOR Plaintext Block 1 → Ciphertext Block 1
Encrypt(Ciphertext Block 1) XOR Plaintext Block 2 → Ciphertext Block 2

Advantages:

• No padding required
• Can encrypt in units smaller than the block size (e.g., byte by byte) — ideal for streaming
• Decryption can be parallelized

Disadvantages: Encryption cannot be parallelized, and a corrupted ciphertext block corrupts two subsequent decrypted blocks.

Use cases: Streaming media, serial data encryption, real-time processing scenarios.

OFB: High Fault Tolerance, Offline Stream Cipher

OFB (Output Feedback) resembles CFB with one key difference: the feedback comes from the encryption function's output, not from the ciphertext. This means the keystream can be generated entirely independently, ahead of time.

KeyStream1 = Encrypt(IV)
KeyStream2 = Encrypt(KeyStream1)
KeyStream3 = Encrypt(KeyStream2)

Ciphertext Block 1 = Plaintext Block 1 XOR KeyStream1
Ciphertext Block 2 = Plaintext Block 2 XOR KeyStream2

Advantages:

• Corrupted ciphertext bits do not propagate — a flipped bit only affects its corresponding position, not subsequent blocks
• Keystream can be precomputed

Disadvantages:

• Neither encryption nor decryption can be parallelized
• Reusing the same IV with two different plaintexts under the same key is catastrophic — keystream reuse immediately breaks security

Use cases: Satellite communications and other high-bit-error channels where isolated bit flips are acceptable but error propagation is not.

CTR: Best Performance, the Modern Standard

CTR (Counter) mode is one of the most recommended modes in modern systems. It generates a keystream by encrypting a monotonically increasing counter, then XORs it with the plaintext.

Keystream Block 1 = Encrypt(Nonce || Counter=1)
Keystream Block 2 = Encrypt(Nonce || Counter=2)
Keystream Block 3 = Encrypt(Nonce || Counter=3)

Ciphertext Block N = Plaintext Block N XOR Keystream Block N

Advantages:

• Both encryption and decryption are fully parallelizable — extremely high throughput
• No padding required
• Supports random access to any block without processing from the beginning
• Naturally suited for multi-core processors and GPU acceleration

Disadvantages:

• The Nonce must never be reused under the same key. Nonce reuse directly leaks plaintext via XOR keystream reuse attacks.

Use cases: High-performance systems (full-disk database encryption, TLS with GCM). AES-GCM (CTR + authentication tag) is the dominant choice in HTTPS/TLS 1.3 today.

Practical Selection Guide

New project, general-purpose → Prefer AES-GCM (CTR + authentication), which provides both encryption and integrity verification. This is the first choice if your library supports it.

Need compatibility with OpenSSL command line → Use CBC + PKCS7 padding with Passphrase mode.

Streaming data or real-time encryption → CFB or CTR.

High bit-error-rate channels → OFB.

Never use ECB under any circumstances.

Universal Rules for IV and Nonce

Regardless of which mode you choose (except ECB), these rules are non-negotiable:

1. Generate a fresh random IV/Nonce for every encryption operation — never reuse (especially critical for OFB and CTR)
2. The IV does not need to be secret, but it must be transmitted alongside the ciphertext (typically prepended to the ciphertext)
3. The key is what truly needs to be kept secret — a leaked key compromises all encrypted data
4. Never use a fixed string or timestamp as an IV; always use a cryptographically secure random number generator (CSPRNG)

Try It in Your Browser

If you want to test the modes discussed in this article hands-on, the AES Online Encrypt & Decrypt Tool on toolshu.com supports all five modes: CBC, ECB, CFB, CTR, and OFB, with both Base64 and Hex output formats. All operations run locally in your browser — no data is ever uploaded — making it safe for testing and verification.