AES-GCM vs AES-CBC: which mode should you use?

Use AES-GCM for anything new. GCM is authenticated encryption: it encrypts the data and also detects any tampering, it runs in parallel, and it is the one cipher every TLS 1.3 implementation must support. Its single strict rule is never to reuse a nonce with the same key. AES-CBC only encrypts, needs padding and a separate integrity check to be safe, and survives mainly where a format requires it, such as standard HLS video.

Why AES needs a mode

AES on its own encrypts exactly one 16-byte block. A mode of operation defines how to encrypt everything else: how blocks are linked, how the starting value (the IV or nonce) is used, and whether the result is protected against tampering. The same AES key can be perfectly safe in one mode and dangerously weak in another, which is why "AES-256" alone says little. If you need a refresher on AES itself, see AES-256 explained. This article compares the three modes you are most likely to choose between: CBC, CTR and GCM.

CBC: cipher block chaining

In CBC mode, each plaintext block is XORed with the previous ciphertext block before being encrypted; the first block is XORed with a random IV. Identical blocks therefore encrypt differently, which fixes the pattern leak of ECB mode. NIST's rules for CBC are that the IV must be unpredictable, and that the plaintext must be padded to a whole number of blocks, usually with PKCS#7 padding.

Because each block depends on the one before, CBC encryption can't be parallelised, although decryption can. More importantly, CBC provides no integrity at all.

What tampering looks like in CBC

A quick experiment shows the difference. Encrypt the text "Polity lecture 14: Fundamental Rights" with AES-128-CBC, flip a single bit in the first ciphertext block and decrypt it: there is no error. The first 16 bytes come out as garbage, and the "4" in "14" becomes a "5", because flipping a bit in one ciphertext block flips the same bit in the next plaintext block. An attacker who knows the layout of a message can use this to change chosen parts of it. Make the same one-bit change to an AES-GCM ciphertext and decryption fails with an authentication error, returning no plaintext.

Padding oracles

CBC's padding creates a second problem. If a system decrypts modified ciphertext and reveals, through a different error message or a difference in timing, whether the padding was valid, an attacker can use those answers to recover the plaintext without the key. This "padding oracle" was described in 2002 and has resurfaced repeatedly; the 2014 POODLE attack used it against SSL 3.0 (CVE-2014-3566). If you must use CBC, add an HMAC over the IV and ciphertext, verify it before decrypting, and return one uniform error for every failure. This pattern is called encrypt-then-MAC.

CTR: counter mode

CTR mode encrypts a sequence of counter blocks and XORs the result with the data, turning AES into a stream cipher. It needs no padding, both directions run in parallel, and any block can be decrypted on its own, which is handy for seeking within a large file. Like CBC, it has no integrity protection: a flipped ciphertext bit flips the same plaintext bit, silently. And the counter must never repeat under the same key, or two messages share a keystream. CTR is rarely used alone today; its main role is as the encryption engine inside GCM, and in the "cenc" scheme used for DRM-protected video. Our comparison of block vs stream ciphers covers why counter modes behave like stream ciphers.

GCM and authenticated encryption

GCM (Galois/Counter Mode) combines CTR-mode encryption with an authentication tag computed over the ciphertext. It is an AEAD scheme: authenticated encryption with associated data. The associated data is information you want protected against changes but not hidden, such as a student ID, a segment number or a message header. On decryption, GCM checks the tag first and returns either the plaintext or a failure, never altered data.

NIST's specification, SP 800-38D, sets the rules that make GCM safe (NIST SP 800-38D):

• Use 96-bit (12-byte) IVs, the length NIST recommends for interoperability and efficiency.
  
  
• Never repeat an IV under the same key. NIST calls this requirement almost as important as keeping the key secret: a single repeat can let an attacker recover the authentication subkey and forge messages.
  
  
• With random IVs, encrypt no more than 2 to the power 32 messages per key, about four billion, then rotate the key.
  
  
• Keep each message under about 64 GB, the mode's limit of 2 to the power 39 minus 256 bits. Split larger files into chunks.
  
  
• Use the full 128-bit tag. Shorter tags are permitted but weaken forgery protection.
  
  

If you can't guarantee unique IVs, for example because several servers encrypt under one key without coordination, AES-GCM-SIV (RFC 8452) is a variant where a repeated nonce reveals only whether two messages were identical.

Performance

On processors with AES instructions, GCM is usually much faster than CBC encryption, because GCM's blocks can be processed in parallel while CBC's must wait for each other. On one Apple M3 Max laptop running OpenSSL 3.6, a single core processed 16 KB buffers at these rates (September 2026; for comparison only, and your numbers will differ):

The gap between CBC encryption and decryption, roughly nine to one here, follows from how the mode works, as NIST's description of it notes: encryption is a chain, decryption is not. GCM gives up some of CTR's speed to compute the tag and still runs several times faster than CBC encryption. On phones without AES instructions, all AES modes slow down, and ChaCha20-Poly1305 is usually the better choice.

Which mode where: TLS, HLS, CENC and storage

Why HLS still uses CBC

HLS's encryption method is fixed by its specification, and every player supports it, so changing it would break compatibility. Its job is also different from TLS's. Segments usually travel over HTTPS, which already detects tampering in transit, and the threat that matters for paid video is someone getting the key, not someone editing ciphertext. The classic CBC attack needs a system that tells the attacker whether decrypting modified ciphertext succeeded, and a player decrypting segments for its own user isn't usually in that position. That is why the cipher mode matters far less in HLS than how the key is delivered, as our guide to HLS AES-128 explains. For how one file can serve several DRM systems, see CENC and CBCS.

Key takeaways

• AES-GCM encrypts and authenticates; AES-CBC and AES-CTR only encrypt.
  
  
• CBC is malleable and exposed to padding oracles; if you must use it, add an HMAC and check it first.
  
  
• GCM's one hard rule: never reuse an IV under the same key, and rotate keys before NIST's limits.
  
  
• On modern CPUs GCM is several times faster than CBC encryption.
  
  
• TLS uses GCM, standard HLS uses CBC, DRM formats use CTR or a CBC pattern, and disks use XTS.
  
  

Frequently asked questions

Is AES-GCM secure?

Yes. AES-GCM is one of the most widely used and studied encryption modes, and it is the cipher every TLS 1.3 implementation must support. Its security depends on correct use: a unique 96-bit nonce for every message under a given key, the full 128-bit tag, and key rotation before NIST's limit of about four billion messages when nonces are random. Use a well-maintained library and let it generate nonces rather than writing your own.

Is AES-GCM AEAD?

Yes. AES-GCM is an AEAD scheme, meaning authenticated encryption with associated data. It encrypts the message, and it authenticates both the ciphertext and any associated data you supply, such as a user ID or a record number, which is checked but not encrypted. If anything has been changed, decryption fails instead of returning altered data. ChaCha20-Poly1305 and AES-CCM are other AEAD schemes.

Is AES-GCM quantum safe?

The AES part is considered safe against known quantum attacks at 128-bit key sizes and above. NIST's draft transition plan rates AES-128 as meeting its lowest post-quantum security category and AES-256 its highest. The real quantum risk is to the RSA or elliptic-curve key exchange that often delivers the AES key, which is why browsers are adding post-quantum key exchange. See whether AES-128 is still secure.

Is AES-CBC still secure?

AES-CBC still keeps data confidential when the IV is random and unpredictable, but it doesn't detect tampering, and it has a long history of padding-oracle attacks when errors are exposed. That is why TLS 1.3 dropped it. It remains acceptable where a format requires it, such as HLS video, or when paired with an HMAC checked before decryption. For new designs, choose AES-GCM.