Protect & Encrypt · Field note
AES-CBC vs AES-GCM: what changed and why modern libraries default differently
Compare AES-CBC and AES-GCM, including integrity, IVs, authentication tags, AAD, and common decryption failures.
Before you start
Run the workflow once with a disposable value, then do a decrypt or restore check before you share anything real.
AES-CBC still appears in deployed systems and file formats. AES-GCM is now common for new application encryption because it authenticates the ciphertext as well as encrypting it.
The useful question is not whether CBC ever worked. It is why GCM changes the safety and debugging story.
In brief
What it is: AES-CBC is a confidentiality mode that typically requires separate integrity protection, while AES-GCM is an authenticated-encryption mode that provides confidentiality and integrity together.
Why it matters: The difference affects failure behavior, implementation risk, and what metadata the tool or library must expose.
Watch for: Migrating to GCM is not just changing a mode name. It changes how IVs, tags, and decryption failures should be handled.
CBC needs a separate integrity design
CBC can be appropriate when an existing protocol defines the full construction. By itself, however, AES-CBC provides confidentiality only. The system must also generate an unpredictable IV, add an integrity mechanism such as a correctly ordered MAC, and verify integrity before using plaintext.
GCM changes what success and failure mean
In GCM, decryption succeeds only when the key, nonce, ciphertext, authentication tag, and any additional authenticated data (AAD) match. An authentication failure intentionally does not reveal which field was wrong, and the receiver must not use unauthenticated plaintext.
- CBC: confidentiality mode, integrity must be handled separately.
- GCM: authenticated-encryption mode with tag-based integrity checking.
- Migration means teaching users about IVs, tags, and failure semantics.
OpenSSL enc output is a separate workflow
The openssl enc command supports CBC ciphers but does not support GCM or CCM. A Base64 value beginning with U2FsdGVkX1 commonly decodes to an OpenSSL Salted__ envelope; it belongs in the OpenSSL AES Decrypt Checker, not an AES-GCM field set.
Conversely, a GCM payload normally carries the nonce, ciphertext, tag, and sometimes AAD in an application-defined layout. Those values are not interchangeable with an OpenSSL enc envelope.
See it in a small example
The practical difference is that GCM makes integrity part of the normal success-or-failure path, while CBC needs a separate integrity design around it.
CBC -> confidentiality, integrity must be added carefully
GCM -> confidentiality + integrity in one modern mode
What to verify
- Know whether you are optimizing for compatibility or for a modern safer default.
- For CBC, identify the separate integrity mechanism and when it is verified.
- For GCM, preserve the exact nonce, tag length, AAD bytes, and payload layout.
- Never release plaintext after an authentication failure.
Common questions
Should I migrate every CBC workflow immediately?
Not blindly. Evaluate compatibility and protocol requirements, but prefer authenticated modes for new work where possible.
Does GCM remove the need for careful nonce handling?
No. Correct nonce/IV handling remains essential. Reusing a GCM nonce with the same key can break both confidentiality and integrity.