In one sentence
AES-GCM is a symmetric encryption mode that both hides data and detects tampering in one step — it produces ciphertext plus an authentication tag, so decryption fails loudly if even one bit of the ciphertext or its associated data was altered.
Why it matters
Encryption that only hides data is not enough — an attacker who cannot read your ciphertext can often still flip bits in it and change what it decrypts to. AES-GCM is authenticated encryption (AEAD): alongside the ciphertext it computes an authentication tag, and if anyone tampers with the ciphertext, the tag check fails and decryption refuses to return anything. Confidentiality and integrity in one primitive, which is why GCM is the default for TLS 1.3, disk encryption and the Web Crypto API.
It replaced older patterns for a reason. "Encrypt with AES-CBC, then bolt on an HMAC" works, but it is easy to get the order wrong and open a padding-oracle hole. GCM bakes the integrity in, so there is one thing to configure correctly instead of two things to wire together.
Keys, IVs and tags
Three inputs matter:
- A key (128 or 256 bits). It rarely comes from a human directly — a password is stretched into a key with a slow key-derivation function like PBKDF2 (many thousands of iterations plus a random salt) so that guessing the password stays expensive.
- An IV / nonce (96 bits is standard for GCM). It does not need to be secret, but it must never repeat under the same key — that is the one rule that, if broken, collapses GCM's security. Generate it randomly per message.
- The tag (typically 128 bits), output alongside the ciphertext and required to decrypt. You may also feed in associated data (a header, a filename) that is authenticated but not encrypted.
So a stored ciphertext is really salt || IV || ciphertext+tag — you keep all of it, and the recipient needs only the password to reverse the whole thing.
Try it yourself hands-on
Encrypt a message with a password and watch the salt/IV/ciphertext structure appear.
- Open the AES-GCM Encrypt / Decrypt tool (all WebCrypto, in your browser — nothing leaves the page). Type a plaintext and a password, pick the PBKDF2 iteration count, and encrypt. The output note tells you exactly what it contains: "the salt, IV, and ciphertext (Base64)" — that is the whole self-describing blob you would store or send.
- Paste that Base64 into the decrypt side with the right password — it returns your plaintext. Now change a single character of the ciphertext and try again: decryption fails rather than returning garbage. That is the GCM tag doing its job; a mode without authentication would happily hand you corrupted plaintext.
- Turn the PBKDF2 iterations up (e.g. 600,000) and feel the deliberate slowness — that cost is what makes a weak password expensive to brute-force offline. Note the tool's own "Demo only" banner: it is for learning the mechanics, not a vault for real secrets.
- To see the integrity primitive on its own, the HMAC Generator shows keyed authentication in isolation — the job GCM's tag does internally.
Result: you can point to the salt, the IV and the tag in a real ciphertext and explain why tampering makes decryption fail instead of leaking.
Common misreadings
- Never reuse an IV under one key. Repeating a GCM nonce can leak plaintext relationships and even the authentication key. Random 96-bit IV per message, always.
- A password is not a key. Feed passwords through PBKDF2/scrypt/Argon2 with a salt; using a raw password (or an unsalted hash) as the AES key is a classic mistake.
- Encrypted is not authenticated identity. GCM proves the ciphertext was not altered by someone without the key; it does not tell you who sent it. For sender identity you still need signatures / certificates.