Protect & Encrypt
AES-CBC vs AES-GCM in Modern Libraries
Compare AES-CBC and AES-GCM, including integrity, IVs, authentication tags, AAD, and common decryption failures.
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.
Compare CBC and GCM by their safety properties and debugging behavior.
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.
Worth knowing: A GCM migration includes new IV, authentication-tag, and decryption-failure handling.
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 can come from any of those inputs. The receiver must discard the result when authentication fails.
- 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.
- Release plaintext only after authentication succeeds.
Common questions
Should I migrate every CBC workflow immediately?
Evaluate compatibility and protocol requirements, and prefer authenticated modes for new work where the ecosystem supports them.
Does GCM remove the need for careful nonce handling?
Correct nonce/IV handling remains essential. Reusing a GCM nonce with the same key can break both confidentiality and integrity.
