AES-GCM vs CBC: which mode to use, and three common mistakes

AES-GCM is the only mode most applications should reach for in 2026. Everything else is a compatibility footnote. The AES algorithm itself is not the weak link — it is the configuration around it that turns secure encryption into something trivially broken.

Most guides to AES encryption online fall into one of two traps: they drown you in algorithm internals such as SubBytes and MixColumns, or they hand you a tool without explaining which mode to pick, what an IV does, or why your password is not a key. This post sits in the gap between those two extremes. By the end you will know which mode to use, why the other three are worse, what an IV is and why reusing one is catastrophic, and how to turn a passphrase into a real encryption key. If you want to skip straight to the tool, the Tool Matic AES Encrypt / Decrypt utility runs entirely in your browser using the Web Crypto API — your plaintext, keys, and IVs never leave your device.

What AES actually is — the 90-second version

AES (Advanced Encryption Standard) is a symmetric block cipher adopted by NIST in FIPS 197. It was originally named Rijndael after its designers, Vincent Rijmen and Joan Daemen. It encrypts data in fixed 128-bit blocks using a secret key of 128, 192, or 256 bits, running 10, 12, or 14 rounds of substitution and permutation respectively.

Symmetric means the same key encrypts and decrypts. That makes AES fast and suitable for bulk data — it is the workhorse behind TLS, file encryption, disk encryption, and countless messaging protocols. The trade-off is key distribution: if you lose the key, you lose the data, and if an attacker obtains it, they can read everything.

AES is reversible by design. That makes it the wrong tool for password storage. Passwords should be hashed with a slow, salted one-way function such as bcrypt, scrypt, or Argon2id. If you need to generate a hash, use the Tool Matic Hash Generator instead.

The four AES modes you will see — and the one to actually use

AES by itself only defines how to encrypt a single 128-bit block. Real messages are longer, so we use a mode of operation to chain blocks together. Here are the four you will encounter, ordered from worst to best.

ECB — Electronic Codebook

ECB encrypts each block independently with the same key. Identical plaintext blocks always produce identical ciphertext blocks. The result is deterministic and leaks patterns across the entire message.

The classic demonstration is the “ECB penguin.” Take an image of Tux the Linux penguin, treat each pixel block as plaintext, and encrypt it with AES-ECB. The ciphertext still looks like a penguin, because every block of sky blue encrypts to the same block of ciphertext, and every block of black encrypts to the same block of ciphertext. The outline, the shading, and the structure are all preserved. ECB is not a mode you should use for anything real.

CBC — Cipher Block Chaining

CBC was the default for years and still appears in older protocols. Before encrypting each plaintext block, CBC XORs it with the previous ciphertext block. This breaks ECB’s deterministic pattern: identical plaintext blocks no longer produce identical ciphertext, because each block’s encryption depends on everything that came before it.

CBC requires a random 16-byte IV for every encryption operation. The IV is sent alongside the ciphertext; it does not need to be secret, but it must be unpredictable and unique.

The fundamental limitation of CBC is that it provides confidentiality only. If an attacker flips bits in the ciphertext, the tampered block decrypts to unpredictable garbage, but the decryption routine itself succeeds silently. You cannot tell whether the data was modified unless you add a separate Message Authentication Code in an encrypt-then-MAC pattern. If you need an HMAC for that, the Tool Matic HMAC Generator can help.

CTR — Counter mode

CTR turns AES into a stream cipher. It encrypts a counter value with the key to produce a keystream, then XORs that keystream with the plaintext. Because XOR is its own inverse, the same operation decrypts. No padding is needed, and both encryption and decryption are fully parallelizable.

CTR is fast and provably secure when used correctly, but — like CBC — it provides no integrity. A flipped bit in the ciphertext flips the corresponding bit in the plaintext. An attacker who knows part of the plaintext can flip bits in the ciphertext to change the decrypted message in predictable ways. You still need authentication on top.

GCM — Galois/Counter Mode

GCM combines CTR-mode encryption with a Galois-field authentication tag in a single pass. It gives you confidentiality and integrity together: if even one bit of the ciphertext, the additional authenticated data, or the authentication tag is altered, decryption fails loudly with an error instead of producing garbage.

The authentication tag is typically 16 bytes and is appended to the ciphertext. When you decrypt, GCM re-computes the tag from the ciphertext and compares it to the one you supplied. A mismatch means the data was tampered with or corrupted, and the plaintext is not released.

For new work in 2026, use AES-GCM. CBC and CTR are kept for compatibility with older systems and specific protocols, but there is no good reason to reach past GCM for fresh implementations.

The IV is not optional — and reusing one is the worst mistake you can make

An IV (Initialization Vector), or nonce (number used once) in modes such as GCM, is a random value that must be different for every encryption operation under the same key. It is not secret — you typically prepend it to the ciphertext or send it alongside — but it must be unpredictable and never reused.

Without a unique IV, encrypting the same plaintext twice produces the same ciphertext. That leaks whether two messages are identical, which is often enough to break a protocol. In CBC the IV is 16 bytes; in GCM the nonce is 12 bytes. Both are generated with a cryptographically secure random number generator.

For GCM, the stakes are far higher. AES-GCM uses a 12-byte nonce. Reusing a nonce with the same key is catastrophic: it does not merely leak patterns, it can allow an attacker to recover plaintext and forge new authentic ciphertexts. This happens because GCM’s security proof relies on every nonce being unique; when that assumption breaks, the authentication guarantee collapses and the confidentiality follows.

This is the single most common AES bug in production systems, and it represents the difference between “my encryption leaks some information” and “my entire cryptographic scheme is broken.” Always generate a fresh random nonce for every encryption. If you need to generate raw random bytes for an IV or a salt, the Tool Matic Random String Generator can produce them.

A passphrase is not a key — why PBKDF2 exists

A 256-bit AES key has 2^256 possible values. A typical English password has far less entropy — perhaps 40 to 60 bits, and often less if it is based on dictionary words or common substitutions. If you feed a password directly into AES as a key, you are not getting 256-bit security; you are getting whatever security your password provides, which is usually not enough to resist offline brute force.

Key-derivation functions solve this by stretching a low-entropy passphrase into a full-length key. PBKDF2 (Password-Based Key Derivation Function 2) takes your passphrase, a random salt, and an iteration count, then applies many rounds of HMAC-SHA256 to produce a key of the desired length. OWASP currently recommends at least 600,000 iterations for PBKDF2-HMAC-SHA256. The salt is random and can be public — it just needs to be unique per password so that identical passwords do not produce identical keys.

Modern alternatives such as Argon2id and scrypt are memory-hard and resist GPU-based cracking better than PBKDF2, but PBKDF2 remains widely supported by the Web Crypto API and is a solid default when Argon2 is unavailable.

If you are using a passphrase rather than a raw key, make it strong. The Tool Matic Password Generator can create one with sufficient entropy to resist dictionary attacks.

The privacy question most AES posts skip — does my plaintext leave the device?

Most online AES tools work like this: you paste your plaintext into a form, the browser sends it to a server, the server encrypts it, and the server returns the ciphertext. Your data has left your device, traveled across the internet, and been processed on someone else’s computer. That is the standard client-server model, and it is how most web applications work.

There is an alternative. A browser-based tool that uses the Web Crypto API performs the entire AES operation inside your browser. The plaintext, the key, and the IV never leave your device. The server only serves the static page; the computation happens in a browser-native cryptographic library that is audited as part of the browser’s security release cycle.

The Tool Matic AES Encrypt / Decrypt tool takes this approach. It processes everything locally using the Web Crypto API — your data is not uploaded to a server.

Why decryption fails — a quick troubleshooting checklist

When decryption fails, work through this list before assuming the data is lost:

• Wrong key or passphrase — the most common cause. Double-check that you are using the same key or passphrase that was used for encryption, and that any PBKDF2 parameters (salt, iterations) match.
• Wrong IV or nonce — GCM decryption requires the exact same 12-byte nonce that was used for encryption. It is usually prepended to the ciphertext. If you strip it or use a different one, decryption will fail.
• Wrong mode — trying to decrypt a CBC ciphertext with GCM, or vice versa, will always fail. The mode is not auto-detected; you must specify it.
• Wrong output format — ciphertext may be encoded as Base64 or hex. Converting between them incorrectly, or copying with line breaks, corrupts the data.
• Corrupted ciphertext — a single flipped bit breaks the block. For GCM this is actually good news: the authentication tag will not match, and decryption fails instead of returning silently tampered data.
• GCM authentication tag mismatch — if the tag was truncated, altered, or computed with the wrong additional authenticated data, GCM refuses to decrypt. This means tampering was detected.

Putting it together — a 60-second recipe

If you need to encrypt something today and do it correctly:

1. Pick AES-GCM.
2. Use a 256-bit key (or derive one from a strong passphrase with PBKDF2 and at least 600,000 iterations).
3. Generate a fresh random 12-byte nonce for every encryption and prepend it to the ciphertext.
4. Send or store the nonce + ciphertext + authentication tag together.
5. On decryption, verify the tag before using the plaintext. If verification fails, the data was tampered with.

You can try this right now with the Tool Matic AES Encrypt / Decrypt tool. It supports AES-GCM, CBC, CTR, and ECB with both raw keys and passphrase-based key derivation, and it runs entirely in your browser — your keys, IVs, and plaintext never leave your device.

FAQ

What is the difference between AES-128 and AES-256?

AES-128 uses a 128-bit key and 10 rounds; AES-256 uses a 256-bit key and 14 rounds. AES-128 is sufficient for almost all current use cases. AES-256 provides a margin of safety against future advances, including some post-quantum estimates, but both are considered secure when used correctly. The practical difference is smaller than the marketing around it suggests.

Is AES encryption secure?

Yes, when configured correctly. AES itself has no known practical attacks. The vulnerabilities appear in how it is used: weak modes such as ECB, reused nonces especially in GCM, hardcoded keys, and insufficient key derivation. Secure AES means GCM, a fresh nonce every time, and a key with real entropy.

Can I use AES to store passwords?

No. AES is reversible — anyone with the key can decrypt the passwords. Passwords should be hashed with a slow, salted one-way function such as Argon2id, bcrypt, or scrypt. For hashing, use the Tool Matic Hash Generator.

Why does my decryption fail?

Usually because of a mismatch in one of the parameters: key, nonce, mode, or encoding. With GCM, an authentication-tag mismatch is the most informative failure — it means the ciphertext was tampered with or corrupted, and the tool protected you from using bad data.

Is browser-based AES encryption safe?

Yes, when it uses the browser’s native Web Crypto API. That API is implemented by the browser vendor, audited as part of the browser’s security release cycle, and runs in a separate sandboxed context. The important caveat is that the tool must actually use it client-side and not send your data to a server.