← Back to Blog Cryptography

AES Modes Explained: CBC, GCM, OCB, CCM

12 min read

The Advanced Encryption Standard (AES) only knows how to encrypt one 128-bit block at a time. That is a problem because real-world data, such as files, network packets, and database records, is almost never exactly 128 bits long. To bridge this gap, cryptographers wrap AES inside a "mode of operation" that defines how to glue many blocks together into a useful encryption pipeline.

Picking the right AES mode is one of the highest-impact decisions an engineer can make. The wrong mode silently breaks confidentiality, integrity, or both. NIST publishes the official catalog of approved modes in the SP 800-38 series. This article walks through the four most important members: CBC, GCM, OCB, and CCM. By the end you will know which one to pick for which job, why CBC is now considered legacy, and why GCM became the modern default.

Why You Cannot Just Use AES Directly

The most basic mode, called Electronic Codebook (ECB), simply chops the plaintext into 128-bit blocks and encrypts each one independently. ECB is forbidden in any modern protocol because identical plaintext blocks produce identical ciphertext blocks. The famous "ECB penguin" image, where you can still see the penguin's outline through the encrypted bitmap, is the canonical demonstration. ECB hides individual bytes but leaks structural patterns.

Every other mode adds chaining or randomization to break this pattern. The art is in how the chaining is done and whether the mode also provides authentication. Read more in AES-256-GCM Explained.

CBC: The Legacy Workhorse

Cipher Block Chaining (CBC) was specified in NIST SP 800-38A in 2001. Its design dates back to the IBM Lucifer days of the 1970s. CBC works by XORing each plaintext block with the previous ciphertext block before encrypting. The first block uses an Initialization Vector (IV) instead.

The math is simple. If C0 is the IV, then for block i:

C[i] = AES-Encrypt(K, P[i] XOR C[i-1])

Decryption reverses the chain. CBC was the default in TLS 1.0 and 1.1 and remains common in disk encryption containers and legacy file formats.

CBC has three classic problems:

It is not authenticated. CBC without a separate MAC lets an attacker manipulate ciphertext blocks. Padding-oracle attacks like POODLE (2014) and Lucky Thirteen (2013) exploited unauthenticated CBC in TLS to recover plaintext.
It cannot be parallelized for encryption. Each block depends on the previous ciphertext, so encryption is strictly sequential. Decryption can be parallelized.
It requires padding for messages that are not a multiple of 16 bytes. PKCS#7 padding is standard but adds attack surface (the padding oracle).

CBC remains acceptable when paired with a MAC in encrypt-then-MAC ordering, but no new protocol should adopt it. The IETF removed CBC ciphersuites from TLS 1.3 entirely (RFC 8446).

GCM: The Modern Default

Galois/Counter Mode (GCM) was specified in NIST SP 800-38D in 2007. It is the dominant authenticated encryption mode in the world today, used by TLS 1.3, IPsec, SSH, QUIC, and almost every modern protocol designed after 2010.

GCM combines two things. First, AES-CTR encrypts the plaintext by XORing it with a keystream generated from incrementing counter values. Second, the GHASH function over GF(2 to the 128) computes a 128-bit authentication tag over the ciphertext and any associated (unencrypted) data.

GCM provides AEAD: Authenticated Encryption with Associated Data. The receiver gets confidentiality and integrity in one operation. If even one bit of the ciphertext or tag changes, the receiver rejects the message.

The advantages over CBC are substantial:

AEAD by construction. No need to bolt on a separate MAC.
Parallelizable encryption and decryption. The counter mode underneath has no chaining, so multiple blocks can be encrypted simultaneously.
Hardware acceleration. Modern CPUs implement AES via AES-NI and GHASH via PCLMULQDQ. Throughput on a single x86_64 core regularly hits 5 to 7 gigabytes per second.

GCM has one famous brittleness: nonce uniqueness. A nonce reused under the same key destroys both confidentiality and integrity. The GHASH key can be recovered, allowing forgery of any future message. This is why long-lived AES-GCM keys must use a counter-based nonce, never random.

The standard GCM nonce is 96 bits (12 bytes). A randomly generated 96-bit nonce has a meaningful collision probability after about 2 to the 32 messages. Read more in AES-256-GCM Explained.

OCB: The Fastest Mode That Almost Was

Offset Codebook (OCB), invented by Phillip Rogaway and described in NIST SP 800-38F (where its sibling SIV-AES lives) and IETF RFC 7253 (2014), is widely regarded as the most elegant AEAD mode for AES. It computes encryption and authentication in a single pass with one AES call per block, no extra GHASH or polynomial computation.

OCB benchmarks are routinely 30 percent faster than GCM on hardware without AES-NI and 10 to 20 percent faster on hardware with AES-NI. The mode is provably secure, easy to analyze, and has a clean nonce-misuse profile.

So why does almost nobody use OCB?

Patents. Phillip Rogaway held US patents covering OCB until 2021, when he formally placed the patents in the public domain. By that point, GCM had already become the universal default in TLS, IPsec, and every other major protocol. OCB lives on in a few standards (such as 802.11i WPA3 in some specifications) and in OpenSSL, but it never displaced GCM.

The lesson is mostly historical: technical superiority does not always win when patents and ecosystem inertia are involved.

CCM: The Constrained-Device Specialist

Counter with CBC-MAC (CCM) was specified in NIST SP 800-38C in 2004. It was designed for environments where code size matters more than peak throughput. CCM combines AES-CTR (for confidentiality) and CBC-MAC (for integrity) using only the AES encryption primitive.

The big advantage of CCM is that you only need an AES encrypt circuit. You do not need separate decrypt circuitry, you do not need GHASH multiplication hardware, and you do not need OCB-style mask generation. For a small embedded chip, this is a real win.

CCM is the default mode in:

IEEE 802.15.4, the radio standard underneath Zigbee and Thread.
Bluetooth Low Energy (BLE) link-layer encryption.
IEEE 802.11i (WPA2) in CCMP mode.
TLS 1.2 and 1.3 ciphersuites for embedded use, defined in RFC 6655.

CCM has two drawbacks:

It is a two-pass mode. The MAC is computed first over the entire message, then encryption happens. This means the entire message must be in memory before encryption can finish, which is awkward for streaming.
It is roughly half the speed of GCM on a CPU with AES-NI, because GCM uses parallel counter and the integrity tag computation is more efficient.

For Internet servers, CCM is rare. For sensors, smart locks, and battery-powered devices, CCM is everywhere.

XTS: The Disk Encryption Specialist

XTS (XEX-based Tweaked CodeBook mode with ciphertext Stealing), specified in NIST SP 800-38E in 2010, is a special-purpose mode for "data at rest" encryption on storage devices. It is what BitLocker, FileVault, dm-crypt, and most full-disk encryption schemes use today.

XTS does not provide authentication. It is purely a length-preserving cipher: 16 bytes of plaintext go in, 16 bytes of ciphertext come out, and identical sectors at different positions on disk produce different ciphertext (because the sector index is mixed in as a "tweak").

The lack of integrity is a deliberate trade-off. Storage media require ciphertext to be exactly the same length as plaintext, with no room for tags or nonces. The disk's own error-correcting codes are responsible for catching bit flips, and the sector position acts as a weak form of integrity.

XTS is not a general-purpose mode. Use it only for disk encryption.

SIV and AES-GCM-SIV: Nonce-Misuse Resistance

The nonce-uniqueness requirement of GCM is so brittle that NIST and the IETF eventually standardized "synthetic IV" modes. AES-GCM-SIV (RFC 8452, 2019) is the most prominent. SIV stands for Synthetic Initialization Vector.

In AES-GCM-SIV, the nonce is derived from the message itself using a keyed hash. If the application accidentally reuses a nonce, the worst case is that the cipher reveals "these two messages are identical," not the catastrophic key recovery of plain GCM.

AES-GCM-SIV is recommended for environments where nonce uniqueness cannot be guaranteed, such as databases that encrypt records without a counter or stateless cloud functions that crash and restart.

Quick Decision Guide

For internet protocols (TLS, IPsec, QUIC, SSH): AES-128-GCM or AES-256-GCM. The default everywhere.

For embedded sensors and IoT (Bluetooth, Zigbee, Thread): AES-128-CCM. Smaller code, no hardware GHASH needed.

For full-disk encryption (BitLocker, FileVault, LUKS): AES-128-XTS or AES-256-XTS. Length-preserving, sector-keyed.

For databases and backups where nonces might collide: AES-256-GCM-SIV. Misuse-resistant.

For applications where AES-NI is unavailable: ChaCha20-Poly1305 instead, see ChaCha20 vs AES-GCM.

For new protocol design today: AES-256-GCM with counter-based nonces, plus a key rotation strategy that changes keys before 2 to the 32 messages.

For legacy compatibility only: AES-CBC plus HMAC in encrypt-then-MAC ordering. Avoid for new work.

What QNSQY Uses

QNSQY's file format uses AES-256-GCM as the symmetric AEAD layer. The 256-bit data-encryption key is delivered via a hybrid post-quantum KEM: ML-KEM combined with X25519. The nonce is constructed from a counter, never random. Read more in Hybrid Encryption and ML-KEM Explained.

The header chunk authenticates associated data including the file format version, KEM choice, and DSA choice. This binds the symmetric ciphertext to the post-quantum envelope, preventing downgrade attacks where an attacker tries to swap a hybrid envelope for a classical-only one.

Quantum Resistance Across Modes

Grover's algorithm halves the brute-force complexity of any symmetric cipher. AES-128 in any mode drops to 64 bits of quantum security, which is no longer safe. AES-256 drops to 128 bits, which remains safe. NIST's recommendation for post-quantum readiness calls for 256-bit symmetric keys.

The mode of operation does not change this calculus. CBC, GCM, OCB, CCM, and XTS all inherit the cipher's quantum security. What matters is the key length. Read more in Grover's Algorithm Explained for Layman.

FAQ

Is CBC really broken?

CBC is not broken in the cryptographic sense. The math is fine. The problem is that almost every CBC deployment in practice has been hit by padding-oracle attacks because the surrounding protocol leaked timing or error information. Modern protocols simply removed CBC to eliminate the foot-gun.

Why isn't OCB the default mode?

Patents kept OCB out of TLS, IPsec, and SSH for over a decade. By the time the patents lapsed in 2021, GCM was already entrenched.

Should I use AES-128 or AES-256?

For data that must remain confidential after large quantum computers exist, use AES-256. For ephemeral session traffic, AES-128 is faster and still safe.

What about AEAD without a nonce?

There is no such thing in modern cryptography. Even SIV modes have a nonce; they just derive it deterministically from the message. The nonce is what gives AEAD its non-malleability guarantees.

Why does Bluetooth use CCM instead of GCM?

Bluetooth Low Energy chips run on coin-cell batteries with milliwatts of power and kilobytes of RAM. CCM uses only the AES encryption circuit, no GHASH multiplier, no parallel counter pipeline. The smaller silicon footprint matters more than peak throughput on a wearable.

Sources

NIST SP 800-38A: Recommendation for Block Cipher Modes of Operation: Methods and Techniques. https://csrc.nist.gov/pubs/sp/800/38/a/final
NIST SP 800-38C: Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality. https://csrc.nist.gov/pubs/sp/800/38/c/final
NIST SP 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC. https://csrc.nist.gov/pubs/sp/800/38/d/final
NIST SP 800-38E: Recommendation for Block Cipher Modes of Operation: The XTS-AES Mode for Confidentiality on Storage Devices. https://csrc.nist.gov/pubs/sp/800/38/e/final
IETF RFC 7253: The OCB Authenticated-Encryption Algorithm. https://www.rfc-editor.org/rfc/rfc7253
IETF RFC 8452: AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption. https://www.rfc-editor.org/rfc/rfc8452
IETF RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3. https://www.rfc-editor.org/rfc/rfc8446

Protect Your Data Before Q-Day Arrives

QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.

Try QNSQY