How to Choose an AES Mode: Why ECB Is Unsafe, and How CBC Differs from GCM

AES is a block cipher that encrypts only 16 bytes at a time; longer plaintext needs a "mode of operation" to chain the blocks together. ECB produces identical ciphertext for identical plaintext and therefore leaks data patterns — it should never be used. When you need authenticated encryption, choose GCM; when compatibility comes first, choose CBC + HMAC. To experiment hands-on, try our AES tool — your key never leaves the browser.

ECB: the penguin problem

ECB encrypts each block independently. Encrypt a bitmap with ECB and the color boundaries remain clearly visible — the famous "ECB penguin." Whenever plaintext has repeated structure (JSON fields, protocol headers, image regions), the ciphertext exposes that structure. ECB's only legitimate use is encrypting exactly one block (16 bytes) of random data, such as key wrapping.

Comparing the three modes

Dimension	ECB	CBC	GCM
Pattern leakage	❌ Severe	✅ None	✅ None
Requires IV	No	Yes (unpredictable)	Yes — nonce (never reuse)
Integrity check	None	None (pair with HMAC)	✅ Built-in auth tag
Parallel encryption	Yes	No (decryption yes)	Yes
Padding	Required	Required (PKCS7)	Not needed (stream mode)
Verdict	Forbidden	Usable but fiddly	Recommended

Engineering advice

1. Key length: prefer AES-256; AES-128 is also acceptable. Keys must be 16/32 randomly generated bytes — never use a password directly as a key (derive one with PBKDF2/Argon2 instead).
2. IV/nonce: CBC's IV must be randomly generated per message and transmitted alongside the ciphertext (the IV doesn't need secrecy, only unpredictability); GCM's nonce must never repeat under the same key.
3. Padding: use PKCS7 for CBC/ECB. On decryption failure, report a single generic "decryption failed" — never distinguish "bad padding" from "bad key" (that's how padding oracle attacks happen).

Last updated: 2026-09-04