How to Encrypt Data with AES-GCM
AES-GCM is the workhorse of modern symmetric encryption: fast, hardware-accelerated, and authenticated so it detects tampering. But it has one unforgiving rule — never reuse a nonce under the same key — and a few details that decide whether your implementation is actually safe. This guide walks through encrypting data correctly, from key management to tag verification and rotation.
In plain words
Encrypting data with AES-GCM means using an authenticated mode that both hides and protects your data, and PlayCISO has a free, browser-based AES-GCM Lab to see it in action. Use a strong random key, a unique nonce per message, optional AAD to bind context, and always verify the authentication tag before trusting the plaintext.
The one unforgiving rule: never reuse a nonce under the same key — it breaks both confidentiality and integrity at once. Tag ciphertexts with a key ID so you can rotate keys without re-encrypting everything.
Step by step
- 1
Use authenticated encryption, not plain AES
Encryption alone hides data but does not detect tampering — an attacker can flip bits and your code will happily decrypt garbage or, worse, attacker-chosen changes. AES-GCM is an AEAD mode: it encrypts and produces an authentication tag in one pass, so decryption fails if the ciphertext was altered. Prefer a vetted AEAD (AES-GCM or ChaCha20-Poly1305) over raw CBC or ECB.
- 2
Generate a strong, properly managed key
Use a 256-bit (or 128-bit) key from a cryptographically secure random source, never a password or a value you typed. Keep the key in a KMS, HSM or secrets manager rather than in source code or config checked into version control. The security of everything else depends on this key staying secret and well-scoped to a single purpose.
- 3
Use a unique nonce for every single message
GCM requires a unique nonce (IV) per encryption under the same key — reusing one is catastrophic. Generate a fresh 96-bit random nonce for each message, or use a monotonic counter if you can guarantee it never repeats and never resets. Prepend the nonce to the ciphertext; it is not secret, only unique.
- 4
Understand why nonce reuse is catastrophic
If the same key and nonce encrypt two different messages, GCM leaks the XOR of the plaintexts and, critically, allows an attacker to forge the authentication tag — breaking confidentiality and integrity at once. There is no partial failure here. Treat nonce uniqueness as a hard invariant, and if you cannot guarantee it with random nonces at high volume, consider a nonce-misuse-resistant mode like AES-GCM-SIV.
- 5
Bind context with Additional Authenticated Data
AES-GCM lets you authenticate extra data that is not encrypted — a record ID, a version number, a tenant ID, a file header. The AAD is covered by the tag but travels in the clear, so decryption fails if it is changed. Use it to bind a ciphertext to its context so an attacker cannot move a valid ciphertext to a different record or user.
- 6
Verify the tag and fail closed
On decryption the GCM mode checks the authentication tag. If verification fails, treat the output as nonexistent: discard any produced plaintext, do not act on it, and return a generic error. Never release or use unverified plaintext, and do not reveal whether the tag or padding was the problem. Fail closed, every time.
- 7
Plan key rotation and versioning
Store a key identifier with each ciphertext so you can introduce a new key without re-encrypting everything at once. Rotate keys on a schedule and immediately on suspected compromise, decrypting with the old key and re-encrypting with the new one as data is accessed or in a background job. Keep a bounded count of how many messages a single key encrypts to stay well within GCM safety limits.
Encrypt and decrypt sample data, watch a tampered ciphertext fail the tag check, and see exactly why nonce reuse breaks everything — free, in your browser.
Related
Every PlayCISO cryptography how-to in one place.
Manage a key lifecycleHow to generate, store, rotate and retire the keys AES-GCM depends on.
Sign and verify with HMACIntegrity without confidentiality, and how it differs from AEAD.
All free toolsThe full PlayCISO toolbox of scanners and reference tools.
Frequently asked questions
What makes AES-GCM better than AES-CBC?
AES-GCM is authenticated: it produces a tag that lets the recipient detect any tampering, and it provides this in a single pass. AES-CBC only provides confidentiality, so you must add a separate MAC correctly (encrypt-then-MAC) to get integrity, and getting that wrong has produced many real vulnerabilities such as padding-oracle attacks. GCM bundles both and removes a whole class of implementation mistakes.
Does the nonce need to be secret?
No. The nonce must be unique per message under a given key, but it is not secret and is normally stored or transmitted right alongside the ciphertext. What matters is that the same key and nonce are never used to encrypt two different messages. A common pattern is a 96-bit random nonce prepended to the ciphertext.
What exactly happens if I reuse a nonce?
Reusing a key and nonce pair on two different messages leaks the XOR of their plaintexts and, more dangerously, exposes the GCM authentication key, which lets an attacker forge valid tags for arbitrary messages. Both confidentiality and integrity collapse. If you cannot absolutely guarantee uniqueness, use AES-GCM-SIV, which is designed to degrade gracefully if a nonce repeats.
What is AAD for, and is it encrypted?
Additional Authenticated Data is information you want protected from tampering but do not need to keep secret — things like record identifiers, version numbers, or routing headers. It is not encrypted; it travels in the clear but is covered by the authentication tag, so any change makes decryption fail. Use it to bind a ciphertext to the exact context it belongs in.
What should my code do when tag verification fails?
Treat it as if no plaintext exists. Discard anything the cipher produced, do not process or log the candidate plaintext, and return a single generic error without revealing why it failed. Acting on unverified plaintext or leaking the failure reason can hand an attacker an oracle. Failing closed is the whole point of authenticated encryption.
How often should I rotate an AES-GCM key?
Rotate on a regular schedule and immediately if you suspect compromise. Also rotate before a single key encrypts an enormous number of messages, because GCM has data limits beyond which collision risk rises. Tag each ciphertext with a key identifier so you can roll keys forward without re-encrypting your entire dataset in one go.