AES-CBC vs AES-GCM: what changed and why modern libraries default differently
Compare AES-CBC and AES-GCM in practical terms so legacy compatibility does not get mistaken for a modern default.
Tip
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 many real systems, which is why developers keep encountering it. That legacy presence can make it feel like a modern default even when current guidance and library ergonomics increasingly point toward authenticated modes like GCM.
The useful question is not whether CBC ever worked. It is why GCM changes the safety and debugging story.
Summary
Definition: 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.
Pitfall: Migrating to GCM is not just changing a mode name. It changes how IVs, tags, and decryption failures should be handled.
CBC is not broken because it is old; it is riskier because it needs careful assembly
CBC can still be used safely in the right legacy or protocol-bound context, but it asks more of the implementation. You need correct IV handling and a separate integrity mechanism. That extra assembly is where mistakes happen. GCM moves the default toward a mode that already includes integrity checks as part of the design.
GCM changes what success and failure mean
In GCM, decryption failure is often an authentication failure: the ciphertext, tag, AAD, or nonce/key combination did not line up. That is a feature. It tells you the receiver should not trust the plaintext. In CBC-based workflows, developers sometimes conflate “it decrypted” with “it was safe,” which is exactly the confusion modern defaults try to reduce.
- 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.
Why this is a strong product gap to fill
The current live site still foregrounds AES-256-CBC on the homepage. Adding AES-GCM tooling and guides would not just broaden the crypto surface; it would modernize the default mental model users leave with.
Quick example
Use this when you need one sentence to explain why new libraries prefer GCM.
What to notice: That does not make CBC imaginary. It makes GCM a stronger default story for many new workflows.
CBC -> confidentiality, integrity must be added carefully
GCM -> confidentiality + integrity in one modern mode
Practical check
- Know whether you are optimizing for compatibility or for a modern safer default.
- Treat integrity as mandatory, not optional, in CBC-era workflows.
- When moving to GCM, expose IV, tag, and AAD concepts clearly.
FAQ
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.
Developer workflow
Use this guide as a local handling check before a secret or protected file leaves your machine.
- Start with a harmless value that has the same shape as the real secret.
- Run the matching browser tool and copy the result into a scratch note.
- Run the decrypt, restore, or verification step before you share the real output.
1. disposable input
2. browser-only protect/encrypt step
3. decrypt or restore check
4. share only the intended artifact