GCM vs CBC Mode Comparison

GCM vs CBC: Choosing the Right AES Mode

AES-GCM and AES-CBC are the two most commonly encountered AES modes of operation. They differ significantly in security properties, performance characteristics, and implementation complexity.

Fundamental Difference

AES-CBC provides only confidentiality — it encrypts data but does not detect tampering. A separate MAC (like HMAC-SHA256) must be added for integrity.

AES-GCM provides authenticated encryption — confidentiality and integrity are guaranteed in a single operation. Tampered ciphertext is rejected automatically.

Security Properties Comparison

Property	AES-CBC	AES-GCM
Confidentiality	Yes	Yes
Integrity	No (needs MAC)	Yes (built-in)
Padding required	Yes (PKCS#7)	No
Padding oracle risk	Yes	N/A
IV requirement	Unpredictable (random)	Unique (random or counter)
IV reuse impact	Leaks common prefix	Catastrophic (key recovery)
Ciphertext malleability	Yes	No

Performance

GCM is significantly faster than CBC for several reasons:

1. Parallelism — GCM's counter mode allows encrypting all blocks simultaneously. CBC is inherently sequential because each block depends on the previous ciphertext.

2. No padding — GCM operates as a stream cipher (via CTR mode), so no padding overhead or processing is needed.

3. Hardware acceleration — Modern CPUs have dedicated instructions for both AES (AES-NI) and GCM's polynomial multiplication (PCLMULQDQ/CLMUL).

Benchmark (AES-256, 1 MB data, modern CPU with AES-NI):
  CBC encrypt:     ~800 MB/s (sequential)
  GCM encrypt:     ~4,500 MB/s (parallel + CLMUL)
  CBC + HMAC-SHA256: ~600 MB/s (encrypt + MAC)

Decryption Parallelism

Interestingly, CBC decryption is parallelizable (each block only needs the previous ciphertext block, which is already known). But CBC encryption remains sequential. GCM is parallel in both directions.

Migration from CBC to GCM

When migrating existing systems from CBC to GCM:

1. Verify IV generation — GCM IVs must never repeat. If your CBC implementation reused predictable IVs, the same code for GCM would be catastrophic
2. Remove padding code — GCM does not use PKCS#7 padding
3. Handle the authentication tag — GCM produces a 16-byte tag that must be stored with the ciphertext
4. Update ciphertext format — The stored format changes: IV + Ciphertext + Tag instead of IV + Ciphertext
5. Plan for backward compatibility — Existing CBC-encrypted data still needs to be decryptable during migration

When CBC Is Still Appropriate

• Legacy system compatibility (older hardware/software that does not support GCM)
• Disk encryption with specific sector requirements (XTS mode is often preferred, but CBC variants exist)
• Regulatory requirements that specifically mandate CBC (rare but exists)

Recommendation

For all new applications, use AES-GCM (or ChaCha20-Poly1305 as an alternative). The built-in authentication eliminates an entire class of implementation errors that plague CBC deployments.