Open the TLS cipher suite list in any modern browser and you will find AES-GCM everywhere and AES-CBC almost nowhere. That split did not happen by accident. AES-CBC (Cipher Block Chaining) and AES-GCM (Galois/Counter Mode) both wrap the same 128-bit AES block cipher, but they solve encryption differently enough that one of them has triggered a padding-oracle CVE against a real production product almost every year since 2011, most recently in Apache Tomcat in April 2026. The other one has not. This piece walks through what each mode actually does, what independent benchmarks say about speed on 2025-2026 hardware, what cloud key-management services charge to run them, and how to move a codebase still stuck on AES-256 CBC encryption over to GCM without breaking anything.
The short version of the AES-GCM vs AES-CBC debate: GCM won the argument for new systems years ago, but CBC has not disappeared, and understanding exactly why each mode behaves the way it does matters more than memorizing “GCM good, CBC bad.” Both build on the same AES block cipher and the same key sizes; the difference is entirely in how that block cipher gets chained across a message, and that structural choice is what decides speed, parallelism, and whether an attacker gets a usable signal back from a broken decryption attempt.
What AES-CBC Actually Does
AES-CBC chains blocks together. Each 16-byte plaintext block gets XORed with the previous ciphertext block before encryption, and the very first block gets XORed with a random initialization vector (IV). That chaining is where the name comes from, and it is also why CBC cannot be parallelized during encryption: block three cannot be encrypted until block two’s ciphertext exists. Decryption can run in parallel, but encryption is strictly sequential.
CBC has a second structural quirk: block ciphers only work on fixed-size chunks, so if your plaintext is not an exact multiple of 16 bytes, it needs padding. The dominant scheme is PKCS#7, which appends bytes that describe how many padding bytes were added. That padding byte, and whether a receiver rejects malformed padding differently than it rejects a bad key, is the exact seam that padding-oracle attacks exploit, going back to Serge Vaudenay’s original 2002 paper on the technique.
Critically, plain CBC has zero built-in authentication. It hides data; it does not verify that data arrived unmodified. NIST formalized CBC in Special Publication SP 800-38A, published by Morris Dworkin in December 2001, alongside ECB, CFB, OFB, and CTR. NIST announced in April 2023 that it plans to revise 800-38A, a sign that even the classical confidentiality-only modes are due for a rethink almost 25 years later.
CBC is not a new idea bolted onto AES. The mode itself traces back to IBM’s 1976 description and was standardized for DES in FIPS 81 in 1980, then carried forward largely unchanged when AES replaced DES as the US government’s approved block cipher in 2001. That two-decade head start explains why CBC shows up in so much legacy code: it was the default confidentiality mode for SSL and early TLS from the mid-1990s through the mid-2000s, long before AEAD constructions existed as a standardized category at all. Anything built on top of that generation of cryptographic libraries, and much of it is still running, inherited CBC as its baseline.
What AES-GCM Actually Does
AES-GCM takes a different structural approach. It runs AES in counter mode (CTR) to generate a keystream that gets XORed with plaintext, which means every block can be encrypted or decrypted independently and in parallel, no chaining dependency required. Layered on top of that counter-mode encryption is GHASH, a polynomial authentication function operating over the field GF(2^128), which produces a 128-bit authentication tag alongside the ciphertext.
That tag is the whole point. GCM is an AEAD construction, Authenticated Encryption with Associated Data, meaning confidentiality and integrity ship in a single pass instead of being bolted together from separate primitives. NIST formalized it in SP 800-38D, finalized in November 2007, also authored by Morris Dworkin. As with 800-38A, NIST flagged in a March 2024 note that it intends to revise 800-38D as part of continuing AEAD work, though GCM remains the current recommended standard.
Because GCM produces an explicit tag and decryption simply fails when that tag does not match, there is no ambiguous “padding valid or not” signal for an attacker to probe. That single design choice is why GCM has not produced a POODLE- or Lucky Thirteen-style vulnerability in its 19 years of existence, while CBC keeps producing them in new codebases.
GCM’s adoption curve tracks almost exactly with TLS’s own evolution. RFC 5288 added AES-GCM cipher suites to TLS 1.2 back in 2008, but for years it sat alongside CBC suites as an option rather than a requirement, and plenty of servers kept CBC as their negotiated default well into the 2010s for compatibility reasons. That changed once TLS 1.3 made AEAD mandatory. Today, checking a server’s supported TLS 1.3 cipher suites is the fastest way to confirm whether AES-GCM is actually in use, since TLS 1.3 will not negotiate anything else.
Benchmark Data: What Independent Tests Actually Measure
Performance claims about AES-CBC vs AES-GCM vary more by hardware and AES-NI availability than almost any other factor in cryptography benchmarking. Four independent sources illustrate the spread.
Intel’s own cryptographic performance whitepaper, running OpenSSL 1.1.1f’s openssl speed -mr -evp benchmark with 8 KB buffers, measured AES-128-CBC encryption at 2.64 cycles/byte on an Intel Xeon Scalable processor, versus 0.65 cycles/byte for AES-128-GCM on the same chip. That is roughly a 4x efficiency gap in GCM’s favor when both use AES-NI hardware acceleration. A July 2024 OpenSSL 3.0.14 GitHub performance discussion showed a similar pattern at the application layer: AES-256-GCM completed a fixed workload in 1,045 ms versus 2,122 ms for AES-256-CBC, about 2x faster for GCM.
BearSSL’s published cross-platform benchmark table tells a more hardware-dependent story. Its x86ni implementation of AES-128-CBC encryption reached 679.76 MB/s on amd64 using AES-NI, while its portable “big” implementation, the kind of code that runs on hardware without AES-NI, dropped to 162.88 MB/s, and its constant-time “small” implementation fell to 39.81 MB/s. That three-way spread shows CBC’s raw block-cipher speed depends almost entirely on whether hardware acceleration exists, independent of the GCM comparison.
A widely cited Stack Overflow benchmark on a Raspberry Pi 2, an ARM board with no AES-NI-equivalent instruction set and an unoptimized GCM build, measured AES-CBC at 27 MB/s against AES-GCM at just 6 MB/s, CBC running roughly 4.5x faster in that specific unaccelerated environment. That result is the outlier that matters: GCM’s advantage assumes a reasonably optimized GHASH implementation and carryless-multiplication hardware support (PCLMULQDQ on x86, or equivalent ARM crypto extensions). Strip those out and GCM’s authentication overhead can make it slower than plain CBC on constrained or poorly optimized platforms.
| Source | Hardware | AES-CBC result | AES-GCM result | Winner |
|---|---|---|---|---|
| Intel whitepaper (OpenSSL 1.1.1f) | Xeon Scalable, AES-NI | 2.64 cycles/byte | 0.65 cycles/byte | GCM, ~4x |
| OpenSSL GitHub #24660 discussion | x86-64 server (OpenSSL 3.0.14) | 2,122 ms/workload | 1,045 ms/workload | GCM, ~2x |
| BearSSL public benchmark table | amd64, AES-NI (x86ni impl.) | 679.76 MB/s | not listed in same row set | n/a (CBC-only row) |
| BearSSL public benchmark table | amd64, no hardware accel. (“big” impl.) | 162.88 MB/s | not listed in same row set | n/a (CBC-only row) |
| Stack Overflow user benchmark | Raspberry Pi 2 (ARM, unoptimized) | 27 MB/s | 6 MB/s | CBC, ~4.5x |
The pattern across all four sources: on server and desktop CPUs shipped since roughly 2013 with AES-NI and PCLMULQDQ, AES-GCM wins by 2x to 4x. On older or embedded hardware lacking those instructions, the outcome flips, and CBC’s simpler arithmetic can pull ahead. That nuance rarely survives into marketing copy, but it is the reason embedded and IoT teams still evaluate CBC seriously instead of defaulting to GCM on principle.
It also explains why “which is faster” is the wrong first question for most teams. The right first question is whether the target CPU actually carries AES-NI and PCLMULQDQ (or the equivalent ARMv8 crypto extensions), because that single fact predicts the benchmark outcome better than anything else in this comparison. A cloud VM, a modern laptop, and any phone shipped in the last several years will have both. A ten-year-old microcontroller, a low-cost IoT sensor, or some older network appliances may have neither, and that is exactly the population where the Raspberry Pi 2 result applies rather than the Xeon Scalable result.
AES-GCM vs AES-CBC: Full Technical Comparison
| Property | AES-CBC | AES-GCM |
|---|---|---|
| NIST specification | SP 800-38A (Dec. 2001) | SP 800-38D (Nov. 2007) |
| Underlying structure | Block chaining, sequential | Counter mode + GHASH, parallel |
| Built-in authentication | None (requires separate HMAC) | Yes, 128-bit GHASH tag |
| Parallelizable encryption | No | Yes |
| Parallelizable decryption | Yes | Yes |
| Padding required | Yes, typically PKCS#7 | No, stream-style XOR |
| IV/nonce reuse risk | Weakens confidentiality | Catastrophic; breaks authentication |
| Typical IV/nonce size | 16 bytes | 12 bytes (96-bit recommended) |
| AES-NI speedup available | Yes, encryption not parallel | Yes, fully parallel |
| TLS 1.3 cipher suite support | Not supported | TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384 |
| Associated data (AAD) support | No | Yes, native |
| Common 2026 use cases | Legacy TLS 1.2, some disk encryption, older VPN configs | TLS 1.3, cloud KMS, modern VPNs, disk encryption via XTS variant |
The Padding Oracle Problem, and Why It Keeps Coming Back
Three named attacks put CBC’s authentication gap on the map. BEAST (CVE-2011-3389, disclosed September 2011) exploited predictable IVs in TLS 1.0’s CBC implementation to recover session cookies via chosen-plaintext injection. Lucky Thirteen (CVE-2013-0169, disclosed February 2013) used timing differences in how servers validated CBC padding and MAC checks to run a statistical plaintext-recovery attack against TLS and DTLS. POODLE (CVE-2014-3566, disclosed October 2014) targeted SSL 3.0’s undefined CBC padding bytes directly, and a related variant affecting some TLS 1.x CBC implementations was tracked separately as CVE-2014-8730 in early 2015.
What is less widely appreciated is that padding-oracle bugs against CBC did not stop in 2015. They have shown up in production software every year since, because “implement constant-time CBC padding validation correctly” turns out to be a genuinely hard engineering problem that GCM sidesteps by construction. The last eighteen months alone produced five separate CVEs.
| CVE | Product | Disclosed | Fixed in |
|---|---|---|---|
| CVE-2025-7071 | Oberon microsystems ocrypto library | Aug. 2025 | 3.9.2 (affected 3.1.0-3.9.1) |
| CVE-2025-59438 | Mbed TLS legacy cipher API | Oct. 15, 2025 | 3.6.5 (affected up to 3.6.4) |
| CVE-2025-68931 | Jervis library (Jenkins job DSL/pipeline) | Jan. 13, 2026 advisory | Patched release, per advisory |
| CVE-2026-32935 | phpseclib AES-CBC unpadding | Mar. 19, 2026 | 3.0.50 (affected 3.0.0-3.0.49) |
| CVE-2026-5504 | wolfSSL PKCS7 CBC decryption | Apr. 14, 2026 (NVD) | Patched release, per advisory |
| CVE-2026-29146 | Apache Tomcat EncryptInterceptor | Apr. 9, 2026 | 11.0.19 / 10.1.53 / 9.0.116 |
| CVE-2026-13182 | Telerik UI for ASP.NET AJAX (chained to RCE) | Sept. 7, 2026 writeup | 2026.2.708 (Q2 SP1) |
The Apache Tomcat case is instructive because Tomcat is not an obscure library. Its EncryptInterceptor, used in default clustering configurations, decrypted CBC-mode ciphertext with PKCS7 padding and leaked padding validity through distinguishable error responses, the exact same class of bug POODLE exploited eleven years earlier. The Telerik case went further: researchers chained an unauthenticated AES-CBC padding oracle into full remote code execution on ASP.NET applications, a reminder that “just a crypto bug” in a state-serialization feature can become a complete compromise. Neither bug would have been possible if the underlying design used GCM’s authenticated tag instead of CBC without a MAC.
TLS and Library Deprecation Timeline
TLS 1.3, standardized as RFC 8446 in August 2018, does not merely deprioritize CBC, it removes it from the protocol entirely. TLS 1.3’s cipher suite list is AEAD-only: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, and two constrained-device CCM variants. There is no CBC option to negotiate, full stop. TLS 1.0 and 1.1, the versions most associated with BEAST-class CBC issues, were formally deprecated by RFC 8996 in March 2021 and are disabled by default across current browsers and server stacks.
OpenSSL’s own documentation for the openssl ciphers command defines the “CBC” cipher string as suites “only supported in TLS v1.2 and earlier,” confirming that CBC-mode suites simply do not exist in an OpenSSL 3.x TLS 1.3 handshake. Enterprise platforms have been following the same script on their own schedules: SAP Ariba announced it would deprecate CBC-based TLS 1.2 cipher suites starting January 24, 2025, and Aptem published a similar CBC-suite deprecation effective August 1, 2025, both pointing customers toward GCM and ChaCha20-Poly1305 equivalents. The Mbed TLS project has an open proposal to drop CBC cipher suites outright, citing RFC 9325 guidance that CBC suites should only be used with an Encrypt-then-MAC extension enabled, itself an admission that plain CBC is not considered safe on its own anymore.
The browser side of this story finished even earlier. Chrome added TLS 1.3 support starting with version 67, Firefox with version 61, and Apple shipped it across macOS 10.13 and iOS 11, all clustered around 2018. Every major browser now enables TLS 1.3 by default, which means the practical reality for any public-facing HTTPS service is that most connecting clients already prefer AES-GCM automatically, and the CBC fallback path only fires for the shrinking population still stuck on TLS 1.2 or older client software.
Cloud KMS Pricing: What Encrypt/Decrypt Operations Actually Cost
One thing that does not change based on cipher mode: what the three major clouds charge for symmetric key operations. AWS KMS, Google Cloud KMS, and Azure Key Vault all price standard symmetric encrypt/decrypt calls, whether the underlying mode is CBC or GCM, at the same rate. The cost differences only show up once you move to asymmetric keys or hardware security module (HSM)-backed keys, which matters for budgeting because it means the AES-GCM vs AES-CBC decision is a pure security and performance call, not a line item finance needs to weigh in on.
| Provider | Symmetric encrypt/decrypt | Free tier | Asymmetric / advanced keys |
|---|---|---|---|
| AWS KMS | $0.03 per 10,000 requests | 20,000 requests/month | $0.15 per 10,000 (RSA-2048 stays at $0.03) |
| Google Cloud KMS | $0.03 per 10,000 operations | Per published pricing page | Asymmetric signing billed at same $0.03/10,000 tier |
| Azure Key Vault (software-protected) | $0.03 per 10,000 operations | Per published pricing page | Advanced keys (RSA 3072/4096, ECC): $0.15 per 10,000 |
| Azure Key Vault (HSM-backed, RSA-2048) | $1.00 per 10,000 operations | n/a | — |
| Azure Key Vault (HSM-backed, RSA-3072/4096 or EC) | $5.00 per 10,000 operations | n/a | — |
Practically, this means the migration from CBC to GCM described later in this article carries no direct cloud billing penalty. Whatever you pay per 10,000 AWS KMS, Google Cloud KMS, or Azure Key Vault symmetric calls today, you will pay after switching the mode. The real cost of staying on CBC is not measured in cloud invoices, it is measured in incident-response hours the next time a padding-oracle CVE lands against whatever library your stack depends on.
Where AES-CBC Still Shows Up in 2026
CBC has not vanished, and pretending otherwise leads to bad migration planning. It persists in a handful of specific niches. TLS 1.2 deployments that have not fully sunset legacy client support still negotiate CBC suites as a fallback, particularly for enterprise B2B integrations tied to older middleware. Full-disk encryption tooling historically leaned on CBC-family constructions before most vendors moved to the XTS mode (itself a CBC-adjacent design defined for storage, not communications). Some embedded and industrial control systems still run CBC because the hardware predates AES-NI and a straight cycle-count comparison favors CBC’s simpler arithmetic, matching the Raspberry Pi 2 result cited earlier. And backward-compatibility code paths in libraries like phpseclib, wolfSSL, and Mbed TLS keep CBC implementations alive specifically so older client software does not break, which is exactly the surface area that produced four of the seven CVEs in the earlier table.
Other AES Modes Worth Knowing
CBC and GCM are not the only two options, and a full picture should mention where the others fit. CTR (Counter mode) is GCM’s encryption half without the authentication tag, fast and parallel but with the same no-integrity-check gap CBC has, so it is rarely used unsecured in new designs. XTS, standardized for storage in IEEE P1619 and used by BitLocker, FileVault, and LUKS, is a CBC-family construction purpose-built for disk sectors where GCM’s tag overhead and nonce-management model do not fit well. SIV (Synthetic IV) mode offers nonce-misuse resistance that GCM lacks, useful in systems where a nonce might accidentally repeat, at some cost in performance. None of these compete directly with GCM for general-purpose network encryption, which is why GCM (and ChaCha20-Poly1305, covered separately in our ChaCha20-Poly1305 vs AES-256-GCM comparison) dominates that specific lane.
Two more modes come up often enough to name. CCM (Counter with CBC-MAC), the other AEAD option listed in TLS 1.3 alongside GCM, combines CTR-mode encryption with a CBC-MAC for authentication instead of GHASH, and it shows up mainly in constrained environments like Bluetooth Low Energy and some IoT protocols where GCM’s carryless-multiplication requirement is a poor fit. GCM-SIV, a newer nonce-misuse-resistant variant of GCM standardized in RFC 8452, exists specifically to blunt the catastrophic failure mode of accidental GCM nonce reuse described later in this article, at the cost of requiring two passes over the data instead of one.
Real-World Examples
Abstract mode comparisons are easier to act on with concrete systems attached to them. The table below mixes systems that chose GCM deliberately, systems still running CBC for legacy reasons, and two of the 2026 CVEs discussed earlier, to show what each choice looks like in a shipping product rather than a spec document.
| System | Mode in use | Detail |
|---|---|---|
| TLS 1.3 (all major browsers) | AES-GCM (or ChaCha20-Poly1305) | CBC suites are not offered; RFC 8446 defines AEAD-only cipher suites |
| Apache Tomcat clustering (pre-fix) | AES-CBC with PKCS7 | EncryptInterceptor padding oracle, CVE-2026-29146, fixed in 11.0.19/10.1.53/9.0.116 |
| Telerik UI for ASP.NET AJAX (pre-fix) | AES-CBC, no integrity check | Padding oracle chained to remote code execution, CVE-2026-13182 |
| BitLocker / FileVault / LUKS | AES-XTS (CBC-family, storage-specific) | Not GCM; disk sectors need a different nonce model than network streams |
| AWS KMS symmetric default | AES-256-GCM | Used for envelope encryption of data keys and direct Encrypt/Decrypt API calls |
| wolfSSL PKCS7 module (pre-fix) | AES-CBC | Interior padding bytes unvalidated, CVE-2026-5504, disclosed April 2026 |
Use-Case Recommendations
| Use case | Recommended mode | Why |
|---|---|---|
| New TLS/HTTPS deployments | AES-GCM (via TLS 1.3) | Only option in TLS 1.3; CBC not negotiable |
| API payload encryption at rest | AES-GCM | Built-in tag avoids needing a separate HMAC layer |
| Full-disk / volume encryption | AES-XTS | Purpose-built for fixed-size sector encryption, not GCM or plain CBC |
| Legacy client compatibility (TLS 1.2 only) | AES-GCM where negotiable, CBC only as last-resort fallback with Encrypt-then-MAC | Minimizes padding-oracle exposure per RFC 9325 guidance |
| Constrained/embedded hardware without AES-NI equivalents | Benchmark both; CBC may win on raw cycles | Raspberry Pi 2-class benchmark showed CBC 4.5x faster without GCM acceleration |
| Cloud KMS envelope encryption | AES-256-GCM | Default across AWS KMS, GCP Cloud KMS, and Azure Key Vault symmetric keys |
| Any new code touching PKCS7-padded CBC decryption | Avoid; use GCM or a vetted AEAD library | Five separate 2025-2026 CVEs trace directly to custom CBC padding validation |
Migration Guide: Moving From AES-CBC to AES-GCM
Switching an existing system from CBC to GCM is a protocol change, not a drop-in library swap, because ciphertext produced under one mode cannot be decrypted under the other and because GCM’s nonce rules are stricter. Teams that treat this as a one-line config flip tend to discover the hard way that old ciphertext becomes unreadable the moment the flip happens, or that a reused nonce counter silently breaks authentication for every message that follows. Here is the sequence that avoids breaking production traffic.
- Inventory every place CBC is used: TLS configs, at-rest encryption libraries, VPN configs, custom serialization/session-state encryption (the exact Telerik failure mode).
- Check whether existing CBC usage includes a separate MAC (Encrypt-then-MAC). If it does not, treat it as high priority regardless of TLS status.
- For TLS-facing services, confirm TLS 1.3 support is enabled server-side; this alone forces GCM or ChaCha20-Poly1305 and eliminates CBC suites automatically.
- For application-layer encryption, swap the cipher object to an AES-GCM implementation in your language’s standard crypto library rather than hand-rolling one.
- Generate a fresh, unique 96-bit (12-byte) nonce per encryption operation. Never reuse a nonce with the same key; unlike CBC’s IV-reuse weakening confidentiality, GCM nonce reuse breaks the authentication guarantee outright.
- Store the authentication tag alongside the ciphertext (commonly appended) and verify it on every decrypt before trusting the plaintext.
- Version your ciphertext format (a mode identifier byte or field) so the decrypt path can support both old CBC-encrypted data and new GCM-encrypted data during rollover.
- Re-encrypt data at rest in batches, prioritizing anything reachable by an external decrypt endpoint, since that is the exposure padding-oracle attacks actually need.
- Run interoperability tests against every client version still in production, especially anything that predates TLS 1.3 support.
- Decommission the CBC code path once the rollover window closes, rather than leaving it live as permanent legacy support.
openssl speed -mr -evp aes-128-cbc
openssl speed -mr -evp aes-128-gcm
openssl speed -mr -evp aes-256-cbc
openssl speed -mr -evp aes-256-gcmRunning those four commands on your own target hardware before migrating is the single most useful step in this list. As the Raspberry Pi 2 result showed, published benchmarks from Intel Xeon servers do not automatically apply to your embedded gateway or your CI runner’s CPU.
Common Implementation Mistakes and How to Avoid Them
Most AES-CBC vs AES-GCM security failures trace back to a handful of repeatable implementation mistakes rather than a flaw in the math itself. Knowing them ahead of time is cheaper than finding them in a CVE report.
- Reusing a GCM nonce. This is the single most damaging mistake possible in either mode. Reuse a 12-byte nonce with the same key under GCM and an attacker who sees two ciphertexts can recover the GHASH authentication key, then forge valid ciphertext for any future message. CBC IV reuse is bad too, it leaks whether two messages share a plaintext prefix, but it does not hand over forgery capability the way GCM nonce reuse does.
- Rolling a custom CBC padding check. Every CVE in the padding-oracle table above traces back to a decrypt routine that returned different errors, or took measurably different time, depending on whether the padding was well-formed. Constant-time padding validation is genuinely difficult to get right by hand; use a vetted library function instead of writing one.
- Skipping the Encrypt-then-MAC ordering. If a system must keep CBC for compatibility, the safe pattern is to MAC the ciphertext, not the plaintext, and verify the MAC before attempting to decrypt or unpad anything. MAC-then-encrypt is the exact ordering that let POODLE and Lucky Thirteen work in the first place.
- Truncating or predicting the GCM tag. A full 128-bit tag should be used and verified in full. Truncated tags reduce forgery resistance, and any code path that swallows a tag-verification failure instead of aborting decryption defeats the entire purpose of using GCM.
- Treating XTS, CTR, or SIV as interchangeable with GCM. Each of these related modes solves a narrower problem; swapping GCM’s AEAD guarantees for plain CTR to “simplify” a codebase silently removes authentication and reintroduces the exact gap GCM was chosen to close.
Pros and Cons
Laid out side by side, the tradeoffs are less about raw capability and more about what each mode assumes you will get right on your own. CBC assumes the surrounding system adds its own integrity check and handles padding validation without leaking timing information, assumptions that keep failing in practice. GCM assumes the surrounding system generates unique nonces reliably, an assumption that mostly holds because modern libraries handle nonce generation automatically rather than leaving it to application code.
| AES-CBC | AES-GCM | |
|---|---|---|
| Pros | Simple arithmetic, competitive speed without AES-NI, wide legacy support, well-understood for 20+ years | Built-in authentication, parallelizable, no padding needed, mandatory in TLS 1.3, 2-4x faster on AES-NI hardware |
| Cons | No native integrity check, padding-oracle history (7+ CVEs in 18 months), sequential encryption, removed from TLS 1.3 entirely | Catastrophic failure on nonce reuse, GHASH overhead hurts on unaccelerated hardware, slightly larger per-message overhead (tag + shorter nonce) |
What Security Researchers and Standards Bodies Say
The IETF’s own specification work reflects the shift toward authenticated modes. RFC 4106, which defines the use of GCM within IPsec’s ESP protocol, states plainly: “GCM is a block cipher mode of operation providing both confidentiality and data origin authentication,” a description that doubles as the core reason it replaced CBC-plus-separate-MAC constructions in newer IPsec and TLS deployments.
Microsoft’s security engineering guidance for developers frames the same point from a recommendation standpoint, noting that “AES-GCM (Galois/Counter Mode) and AES-CCM (Counter with CBC-MAC) are widely used authenticated encryption modes,” positioning both as the modern default for new development rather than plain CBC.
Kudelski Security’s applied cryptography research team, writing about the persistence of older AES modes in production systems, put the underlying tradeoff this way: “CBC and CTR are probably the most ubiquitous modes of operation for confidentiality; they lie as well at the core of authenticated encryption,” a reminder that CBC and CTR are still the building blocks other constructions rely on, GCM included, even as plain unauthenticated CBC falls out of favor for new designs.
The Verdict: Which Should You Use in 2026
For anything shipping new in 2026, AES-GCM is the default and CBC needs a specific justification to use instead. The performance data backs it up on the hardware most services actually run on: a 2x to 4x throughput advantage on AES-NI-equipped Xeon and equivalent server CPUs, confirmed independently by Intel’s own whitepaper and the OpenSSL project’s own GitHub performance thread. TLS 1.3 has already made the decision for network traffic by removing CBC suites outright. And the security case is not theoretical: seven padding-oracle CVEs against real products in CBC implementations landed between August 2025 and September 2026 alone, from a Jenkins pipeline library to Apache Tomcat’s own clustering interceptor to a Telerik RCE chain.
The exception that survives scrutiny is genuinely constrained hardware without AES-NI or ARM crypto extensions, where an unoptimized GCM implementation’s GHASH overhead can make CBC the faster choice, as the Raspberry Pi 2 benchmark demonstrated. Even there, the fix is usually to find a better-optimized GCM library rather than falling back to unauthenticated CBC, given what fixing a padding oracle after the fact costs compared to benchmarking two crypto libraries up front.
Zoom out past AES-CBC vs AES-GCM specifically and the broader lesson holds across cryptography: authenticated modes beat confidentiality-only modes almost every time integrity matters, which in a networked system is almost always. The same logic is why symmetric encryption design in general has moved toward AEAD as the default rather than pairing a cipher with a bolted-on MAC after the fact. If a 2026 project still defaults to plain AES-CBC without Encrypt-then-MAC, that is worth flagging in code review regardless of how the rest of the comparison shakes out, and it is a good candidate for the kind of audit covered in our broader cryptography coverage.
Frequently Asked Questions
Is AES-GCM always faster than AES-CBC?
No. On modern server and desktop CPUs with AES-NI and PCLMULQDQ support, GCM is typically 2x to 4x faster. On older or embedded hardware without that acceleration, unoptimized GCM implementations can run slower than CBC, as shown in a Raspberry Pi 2 benchmark where CBC reached 27 MB/s against GCM’s 6 MB/s.
Why is AES-CBC considered less secure than AES-GCM?
Plain CBC provides no built-in authentication, so an attacker who can submit modified ciphertext and observe how a server responds to invalid padding can sometimes recover plaintext through a padding-oracle attack. GCM produces an authentication tag as part of encryption, so tampered ciphertext simply fails to decrypt rather than leaking information through error behavior.
Does TLS 1.3 support AES-CBC at all?
No. RFC 8446 defines TLS 1.3’s cipher suites as AEAD-only: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, and two CCM variants. CBC-based suites are not part of the TLS 1.3 specification.
What happens if a GCM nonce gets reused with the same key?
Nonce reuse in GCM is far more damaging than IV reuse in CBC. It can let an attacker recover the authentication key and forge valid ciphertext for future messages, not just weaken confidentiality. This is why GCM implementations require a fresh, unique nonce (typically 12 bytes) for every encryption under a given key.
Is BitLocker or FileVault using AES-CBC or AES-GCM?
Neither, strictly speaking. Full-disk encryption tools generally use AES-XTS, a mode purpose-built for fixed-size storage sectors. XTS shares some lineage with CBC-family designs but is a distinct mode defined separately for disk encryption rather than network communication.
Do cloud providers charge more for AES-GCM than AES-CBC operations?
No. AWS KMS, Google Cloud KMS, and Azure Key Vault all price standard symmetric encrypt/decrypt operations at $0.03 per 10,000 requests regardless of the underlying AES mode. Pricing differences only appear with asymmetric keys or HSM-backed keys.
Can I just switch my application from AES-CBC to AES-GCM without any other changes?
No. Ciphertext encrypted under one mode cannot be decrypted under the other, nonce/IV handling rules differ, and GCM adds an authentication tag that must be stored and verified. Treat it as a protocol migration: version your ciphertext format, support both modes during rollover, and decommission CBC once every client has moved over.
Are there recent real-world examples of AES-CBC vulnerabilities?
Yes. Between August 2025 and September 2026, padding-oracle CVEs were disclosed against Oberon’s ocrypto library, Mbed TLS’s legacy cipher API, the Jervis library used in Jenkins pipelines, phpseclib, wolfSSL’s PKCS7 module, Apache Tomcat’s EncryptInterceptor, and Telerik UI for ASP.NET AJAX, the last of which was chained into remote code execution.
Does choosing AES-128 vs AES-256 matter more than choosing GCM vs CBC?
They answer different questions. AES-128 vs AES-256 is a key-size decision that affects brute-force resistance; AES-GCM vs AES-CBC is a mode-of-operation decision that affects authentication and attack surface. Both key sizes are considered secure through at least 2026, so for most teams the mode choice (favoring GCM) matters more day to day than the key-size choice.
Is AES-GCM well supported on mobile devices?
Yes. Modern ARM chips used in phones ship with dedicated AES and, on recent designs, polynomial-multiplication crypto extensions that accelerate GHASH, so GCM performs well on current-generation mobile hardware. The Raspberry Pi 2-class slowdown applies to older or budget ARM boards without those extensions, not to current flagship or mid-range phones.
