AES-GCM

AES-GCM is an authenticated-encryption mode that provides confidentiality and integrity in one operation. Its security depends critically on never reusing the same nonce with the same AES key.

AES-GCM combines AES in counter mode for encryption with GHASH for authentication. The result is an authenticated-encryption scheme: successful decryption verifies that the ciphertext and authenticated metadata have not been altered.

Each encryption uses a nonce, commonly called an IV in APIs. With GCM, the nonce must be unique for a given key; a random 96-bit nonce is a common choice because it makes accidental reuse extremely unlikely when generated correctly. The nonce does not need to be secret and is normally stored or transmitted alongside the ciphertext.

GCM can authenticate additional data without encrypting it. This is called AAD (Additional Authenticated Data), and it is useful for values such as protocol headers that must be integrity-protected but remain visible.

The authentication tag is produced during encryption and checked during decryption. If ciphertext, AAD, or the tag is modified, decryption should fail rather than return unauthenticated plaintext.

In Java, `Cipher` can be configured with `AES/GCM/NoPadding` and a `GCMParameterSpec` containing the tag length and nonce. Applications should generate a fresh nonce for every encryption under a key and persist enough information to recover the nonce during decryption.

Key points

Interview questions

Why must an AES-GCM nonce never be reused with the same key?

GCM uses the nonce as part of its counter-mode encryption and authentication construction. Reusing a nonce under the same key can expose relationships between plaintexts and can also compromise authentication security. Therefore, applications need a reliable strategy for generating unique nonces. A random 96-bit nonce is common when the probability of collision is acceptably negligible, while counters can provide deterministic uniqueness when managed correctly.

What does AES-GCM authenticate besides the ciphertext?

GCM supports Additional Authenticated Data, or AAD. AAD is supplied to the cipher during encryption and must be supplied unchanged during decryption. It remains unencrypted but is covered by the authentication tag, making it suitable for visible protocol metadata or headers. If the AAD changes, tag verification fails.

How would you store an AES-GCM encrypted value in a database?

A typical representation stores the nonce together with the ciphertext and authentication tag, because the nonce is not secret. The encryption key should be kept separately in an appropriate key-management system rather than alongside the ciphertext. The application must also define how keys are rotated and how records identify the key version used for encryption. On decryption, authentication must succeed before the plaintext is trusted.

What is the difference between encryption and authenticated encryption?

Encryption is primarily about preventing unauthorized parties from learning plaintext. Authenticated encryption adds integrity and authenticity protection, so modifications to the protected data can be detected. AES-GCM is an authenticated-encryption mode. This means an application generally does not need to bolt on a separate MAC merely to detect ciphertext tampering.

What happens when AES-GCM authentication fails in Java?

The `Cipher` operation reports a failure rather than returning trusted plaintext. With the standard JCA API, an authentication failure from GCM decryption is represented by an `AEADBadTagException`, which is a subclass of `BadPaddingException`. Applications should treat this as an invalid or tampered message and should not process the resulting plaintext. Error handling should also avoid leaking unnecessary information about which part of validation failed.