Applications need encryption that protects confidential data without allowing attackers to alter messages unnoticed. AES-GCM provides confidentiality, integrity, and authenticity in one authenticated-encryption mode. section 5.0 section 5.2.3
AES-GCM combines counter-mode encryption with Galois-field authentication. Encryption takes plaintext, a secret key, and an initialization vector (IV), producing ciphertext and an authentication tag. Decryption verifies the tag before returning plaintext. section 5.2 section 5.2.3
Use AES-GCM carefully because its guarantees depend on correct configuration:
- Generate a fresh, unpredictable 96-bit IV with SecureRandom for every encryption; never reuse an IV with the same key. section 5.5.2 section 5.7
- Prefer a 256-bit key and a 128-bit authentication tag, and store keys in secure key storage rather than source code or configuration files. section 5.5.2 section 5.6
- Treat nonce reuse as catastrophic: attackers may recover information about plaintext, recover keys, or forge apparently valid messages. section 5.2.3 section 5.6
- Use a well-tested library or high-level API such as Tink when possible; GCM is fragile when developers mishandle nonces, tags, keys, or errors. section 5.2.3 section 5.5.2
AES-GCM also supports Authenticated Encryption with Associated Data (AEAD). Headers or metadata can remain plaintext while the authentication tag binds them to the encrypted body, detecting tampering or swapping between records. section 5.4
Java encryption and decryption
Java uses Cipher.getInstance("AES/GCM/NoPadding"), a GCMParameterSpec containing a 128-bit tag and 12-byte IV, and a secret AES key. Encryption stores the IV with the ciphertext; decryption separates the IV, verifies the authentication tag through doFinal(), and fails if the data or key is wrong. Use Cipher carefully because it is stateful and not thread-safe. section 5.2.4
Protecting a refunds file
A warehouse service encrypts refunds.json before sending it to a payments service. The payments service decrypts the file and processes it only when authentication succeeds; changing the key or altering the encrypted file causes decryption to fail, so no refunds are processed. section 5.3.2 section 5.6
For standardized encrypted tokens, Nimbus can create and decrypt JWE objects using AES-GCM through a higher-level API. In hybrid encryption, AES-GCM encrypts content while RSA-OAEP protects the AES content-encryption key. section 11.5.2 section 6.3.2
