AES-256-CBC is AES with a 256-bit key in Cipher Block Chaining mode: each block of plaintext is XORed with the previous block of ciphertext before being encrypted, starting from a random initialisation vector, so that repeated plaintext does not produce repeated ciphertext. It provides confidentiality but no built-in integrity check, requires padding, and has been the source of serious attacks when used without a separate authentication step. AES-256-GCM provides confidentiality and integrity together, needs no padding, and has replaced CBC as the default in modern protocols.
CBC still appears in countless tools, libraries, file formats and older protocols, so understanding it matters even as GCM takes over. This guide explains how CBC mode works, the two requirements it imposes, the attacks that follow from missing them, how GCM differs and why it is preferred, and when CBC remains a sensible choice.
Why a mode is needed
AES encrypts exactly one 128-bit block, as the guide to how AES works on this site explains. Encrypting each block of a longer message independently, called ECB mode, is insecure because identical blocks encrypt to identical ciphertext, leaking the structure of the data; the classic demonstration is an encrypted image whose outline remains visible. A mode of operation defines how to apply the block cipher across many blocks so that this does not happen. CBC and GCM are two answers to that problem.
How CBC works
Cipher Block Chaining links every block to the one before it.
- Generate a random 128-bit initialisation vector, the IV, which does not need to be secret but must be unpredictable and different for every message.
- XOR the first plaintext block with the IV, then encrypt the result with AES to produce the first ciphertext block.
- XOR the second plaintext block with the first ciphertext block, encrypt, and so on. Each ciphertext block depends on all the plaintext before it.
- Transmit the IV along with the ciphertext.
Decryption reverses the chain: decrypt each ciphertext block with AES, then XOR with the previous ciphertext block, or the IV for the first block. Decryption can be parallelised because each block needs only the previous ciphertext, which is already known; encryption cannot, because each block needs the previous encryption's output.
Because AES works on whole blocks, CBC requires the plaintext length to be a multiple of 16 bytes. Padding fills the final block, most commonly with a scheme that appends bytes indicating how much padding was added, so the decryptor can remove it.
The two requirements CBC imposes
The IV must be random and unpredictable. If an attacker can predict the IV before choosing a plaintext, they can test guesses about earlier messages. Reusing an IV with the same key reveals whether two messages begin identically. Using a fixed IV, which some tools did, reduces CBC to a leaky version of ECB for the first block. A fresh random IV per message, sent alongside the ciphertext, satisfies the requirement.
The ciphertext must be authenticated. CBC does nothing to detect modification. An attacker who flips bits in a ciphertext block causes predictable changes in the corresponding plaintext block and scrambles the next block. Worse, if the decrypting system reveals whether padding was valid, even indirectly through timing or an error message, an attacker can decrypt the entire message byte by byte without the key. This is the padding-oracle attack, and it has been demonstrated against web frameworks, VPN protocols and TLS itself. The fix is to compute a message authentication code over the IV and ciphertext and verify it before attempting decryption, a construction called encrypt-then-MAC.
Both requirements are met in well-designed systems. Both have been missed in real ones, repeatedly, which is the case for authenticated modes.
How GCM differs
Galois/Counter Mode takes a different approach, described in more depth in the guide to how AES works.
- It encrypts a counter, starting from a unique nonce, and XORs the resulting keystream with the plaintext. No chaining, no padding, any length of data.
- Encryption and decryption can both run in parallel and are very fast with hardware AES support.
- It computes an authentication tag over the ciphertext and any additional associated data, such as headers, and the recipient verifies the tag before using the data. Tampering is detected and the message rejected.
- The nonce need not be random, only unique per key; a counter suffices. It must never repeat, because a repeated nonce leaks the XOR of two plaintexts and can compromise the authentication key.
GCM is authenticated encryption with associated data, and using it correctly means choosing a unique nonce per message and checking the tag. That is a shorter list of requirements than CBC's, and the consequences of the one remaining pitfall are well documented.
Comparing the two
| Property | AES-256-CBC | AES-256-GCM |
|---|---|---|
| Confidentiality | Yes | Yes |
| Built-in integrity | No, needs a separate MAC | Yes, authentication tag |
| Padding | Required, attackable if mishandled | None |
| Parallel encryption | No | Yes |
| Parallel decryption | Yes | Yes |
| Per-message value | Random unpredictable IV | Unique nonce |
| Failure if value repeats | Leaks equality of prefixes | Serious: plaintext XOR and tag key exposure |
| Modern protocol support | Removed from TLS 1.3 | Standard in TLS 1.3, VPNs, messaging |
When CBC is still a reasonable choice
CBC is not broken as a cipher mode; it is easy to use insecurely. It remains appropriate where a format or protocol requires it and integrity is handled correctly, such as older TLS versions with proper MAC handling, some archive and file formats, and interoperability with existing systems. Full-disk encryption uses related non-authenticated constructions, most commonly XTS, because authenticating every sector is impractical, and relies on other properties instead. For any new application where you choose the mode, an authenticated mode is the right default, and CBC should be picked only with a specific reason and a MAC.
A five-point checklist for using CBC safely
- Generate a fresh random IV from a cryptographic random source for every message and send it with the ciphertext.
- Never reuse a key and IV pair.
- Compute a MAC over the IV and ciphertext with a separate key, verify it in constant time before decrypting, and reject on failure without revealing why.
- Use standard padding from a well-tested library, never hand-rolled.
- Ask whether GCM or ChaCha20-Poly1305 would serve instead; if so, use it and skip the list.
What standards bodies and protocol designers say
The preference for authenticated modes is not a matter of taste.
Standards bodies list CBC as an approved confidentiality mode while recommending authenticated encryption for new applications, and publish separate guidance on combining CBC with a MAC precisely because unauthenticated use has caused failures.
The designers of TLS 1.3 removed all CBC cipher suites, citing the history of padding-oracle and related attacks against CBC in earlier versions and the difficulty of implementing CBC with a MAC safely.
Security researchers who have published padding-oracle attacks against real systems emphasise that the flaw was never in AES but in using CBC without authentication and in leaking padding validity, which authenticated modes avoid by construction.
Prefer the mode that fails less
If you are choosing, choose GCM and manage the nonce. If you are stuck with CBC, follow the checklist and authenticate. Either way, the cipher underneath is the same AES-256, and the difference between a secure system and a broken one is entirely in how the blocks are strung together.
Frequently asked questions
What is AES-256-CBC encryption?
AES with a 256-bit key in Cipher Block Chaining mode. Each plaintext block is XORed with the previous ciphertext block before encryption, starting from a random initialisation vector, so identical plaintext blocks produce different ciphertext. It provides confidentiality but no built-in integrity check.
What is the difference between AES-CBC and AES-GCM?
CBC chains blocks and requires padding and a separate integrity mechanism. GCM encrypts a counter to produce a keystream, needs no padding, can run in parallel, and computes an authentication tag that detects tampering. GCM is authenticated encryption; CBC alone is not.
Is AES-256-CBC secure?
The encryption is secure when the IV is random and unpredictable and the ciphertext is protected by a separate message authentication code. Without authentication, CBC is vulnerable to padding-oracle and bit-flipping attacks that have broken real systems. With a MAC applied correctly, it remains acceptable.
Why is GCM preferred over CBC?
Because GCM provides confidentiality and integrity together in one well-defined construction, removes padding and its attacks, runs faster on modern hardware, and is harder to misuse. Modern protocols such as TLS 1.3 dropped CBC entirely in favour of GCM and ChaCha20-Poly1305.
When is CBC still a reasonable choice?
For compatibility with existing systems and formats that specify it, and for disk encryption variants where authenticated modes are impractical, provided integrity is handled separately. For new designs, an authenticated mode such as GCM is the recommended default.
Last reviewed and updated on . Plain text version: /encryption/aes-cbc-vs-gcm.txt.
