AES-GCM vs AES-CBC
What's the difference between these two AES modes — and why does it matter which one you use?
Quick Answer
AES-GCM is preferred. It provides authenticated encryption (AEAD) — combining confidentiality and integrity in one pass, with hardware acceleration and native parallelism. AES-CBC provides confidentiality only and is vulnerable to padding oracle attacks when misused. TLS 1.3 mandates AEAD-only cipher suites; use AES-GCM or ChaCha20-Poly1305.
- ✓Building any new system or API
- ✓You need authenticated encryption (AEAD)
- ✓Targeting TLS 1.3 / modern HTTPS
- ✓Performance matters (hardware-accelerated)
- ✓You can guarantee unique nonces per encryption
- ⚠Starting any new implementation
- ⚠You cannot guarantee a MAC (encrypt-then-MAC)
- ⚠Decryption errors might be observable to attackers
- ⚠You are building public-facing APIs
- ⚠Migrating off TLS 1.0/1.1/SSL 3.0
Head-to-Head Comparison
| Aspect | AES-GCM | AES-CBC |
|---|---|---|
| Provides authentication? | Yes — AEAD with 128-bit authentication tag | No — ciphertext only |
| Performance | Excellent — hardware-accelerated (AES-NI + CLMUL) | Good — AES-NI, but no GCM parallelism |
| Parallelizable encryption? | Yes — blocks are independent (CTR mode) | No — each block depends on previous ciphertext |
| Error propagation | Isolated — invalid tag rejects entire message | 2-block cascade — one corrupt block corrupts next |
| Main security risk | Nonce reuse → plaintext recovery + forgery | Padding oracle (POODLE, BEAST, Lucky 13) |
| Recommended today? | Yes — preferred for all new systems | Legacy only — migrate when possible |
| Typical use cases | TLS 1.3, HTTPS, REST APIs, JWT, disk encryption | Legacy TLS, some older disk encryption schemes |
What Is a Block Cipher Mode?
AES is a block cipher — it encrypts exactly 128 bits (16 bytes) at a time. A mode of operation defines how AES is applied repeatedly to encrypt data longer than one block. The mode determines whether blocks can be processed in parallel, whether a change in one block corrupts others, and — critically — whether the ciphertext is authenticated.
See the Authenticated Encryption and Integrity guide for a comprehensive look at AEAD modes including AES-GCM and ChaCha20-Poly1305.
How AES-CBC Works
CBC (Cipher Block Chaining) XORs each plaintext block with the previous ciphertext block before encrypting it. The first block is XORed with a random Initialization Vector (IV). This chaining makes each ciphertext block depend on all previous plaintext blocks.
C₀ = AES_k(P₀ XOR IV)
C₁ = AES_k(P₁ XOR C₀)
Cₙ = AES_k(Pₙ XOR Cₙ₋₁)
The chaining means encryption is sequential (each block depends on the previous), while decryption can be parallelized. More importantly, AES-CBC provides no authentication — there is no integrity check on the ciphertext. An attacker who can observe decryption error messages can exploit padding to recover plaintext one byte at a time (padding oracle attack).
The POODLE attack (2014) exploited a padding oracle in SSL 3.0 CBC. Lucky 13 exploited timing side channels in CBC implementations. BEAST exploited IV predictability in TLS 1.0 CBC. These attacks motivated TLS 1.3's decision to require AEAD only.
How AES-GCM Works
GCM (Galois/Counter Mode) combines two components: a CTR (Counter) mode stream cipher for encryption, and a GHASH function for authentication.
- CTR mode: AES encrypts an incrementing counter, producing a keystream. The keystream is XORed with plaintext. Since each counter value is independent, all blocks can be encrypted in parallel.
- GHASH: The ciphertext (and optional associated data) is processed through a Galois field multiplication to produce a 128-bit authentication tag. Any modification to the ciphertext produces a different tag.
- Decryption: The tag is verified before any plaintext is returned. If verification fails, the operation is aborted and no plaintext is released — eliminating the padding oracle class of vulnerabilities entirely.
GCM requires a 96-bit nonce that must be unique per (key, message) pair. Modern CPUs with AES-NI and PCLMULQDQ instructions accelerate both the CTR encryption and the GHASH computation, making AES-256-GCM faster in practice than AES-256-CBC on most hardware.
Why GCM Is Preferred in Modern Systems
TLS 1.3 removed all non-AEAD cipher suites. Every TLS 1.3 session uses AES-256-GCM-SHA384, AES-128-GCM-SHA256, or ChaCha20-Poly1305. This was a deliberate response to a decade of CBC-related vulnerabilities.
With CBC, you need to separately add a MAC (HMAC) to authenticate the ciphertext. With GCM, authentication is built in. Fewer moving parts means fewer opportunities for implementation errors.
GCM encryption and decryption are both fully parallelizable — critical for high-throughput applications processing many connections or large files simultaneously.
GCM can authenticate plaintext header data (like protocol version or record sequence numbers) without encrypting it. This is useful for network protocols where headers must remain readable.
Common Misconfigurations
✗ Reusing nonces in AES-GCM
Using the same (key, nonce) pair twice is catastrophic in GCM: an attacker can XOR the two ciphertexts to recover XOR of plaintexts, and the authentication tag is compromised. Always generate a fresh random 96-bit nonce for every encryption operation.
✗ Truncating the authentication tag
GCM produces a 128-bit tag. Some implementations allow truncation to 96, 64, or 32 bits for bandwidth savings. Shorter tags reduce the security margin against forgery. Never truncate below 96 bits. Don't truncate at all unless you have a specific, measured need.
✗ Using AES-CBC without a MAC
A common mistake is using AES-CBC for encryption and assuming it provides integrity. It does not. Any CBC-based scheme must apply encrypt-then-MAC (HMAC-SHA256 over the IV + ciphertext) to resist padding oracle and ciphertext manipulation attacks.
✗ Accepting CBC in TLS downgrade scenarios
If your server still offers CBC cipher suites alongside GCM, a downgrade attack can force the connection to use CBC. Disable all CBC-based suites on servers you control and require TLS 1.2+ with GCM or TLS 1.3.
Use the AES Encrypt/Decrypt tool to see AES-GCM encryption in action — all processing runs locally in your browser.