Authenticated Encryption (AEAD)

Authenticated encryption protects plaintext from being read and detects unauthorized modification. AEAD additionally authenticates associated data (AAD) that remains unencrypted but is bound cryptographically to the ciphertext.

AEAD combines confidentiality and integrity in one encryption operation. A successful decryption verifies that the ciphertext and authentication inputs have not been altered before returning plaintext; otherwise decryption fails.

Associated data (AAD) is authenticated but not encrypted. It is useful for metadata such as a protocol version, message type, or identifier that must remain visible while still being protected against tampering. The same AAD must be supplied during decryption.

AES-GCM is a common AEAD construction available through Java's standard cryptography APIs. It uses a secret AES key, a nonce (also called an IV), plaintext, and optional AAD to produce ciphertext plus an authentication tag.

Nonce management is critical with GCM: a nonce must not be reused with the same key. In typical applications, a fresh randomly generated 12-byte nonce is used for each encryption, and the nonce is stored or transmitted alongside the ciphertext because it does not need to be secret.

An authentication failure must be treated as a failed decryption. Applications should not use partially decrypted data or attempt to ignore an invalid tag.

Key points

• AEAD provides confidentiality and integrity together.
• AAD is authenticated but remains visible in plaintext.
• AES-GCM is an AEAD mode supported by Java's standard cryptography APIs.
• Never reuse a GCM nonce with the same key.
• Authentication-tag failure must cause decryption to fail.

Interview questions

Why must a GCM nonce not be reused with the same key?

GCM relies on nonce uniqueness for security. Reusing a nonce with the same key can reveal relationships between plaintexts and can undermine authentication security. Therefore an application should generate or otherwise guarantee a unique nonce for every encryption under a given key.

How would you use AES-GCM in a Java backend?

I would use the JCA/JCE `Cipher` implementation with `AES/GCM/NoPadding`, a securely generated AES key, and a fresh nonce for each encryption. I would pass protocol metadata through `updateAAD` when it needs authentication without encryption. The serialized result would contain the nonce and ciphertext-plus-tag, while the key would be managed separately through an appropriate secret-management mechanism.

What problem does authenticated encryption solve?

Authenticated encryption protects both confidentiality and integrity. Confidentiality prevents an attacker from learning the plaintext, while integrity lets the recipient detect unauthorized modification. AEAD can also authenticate metadata that does not need to be encrypted.

What is associated authenticated data in AES-GCM?

AAD is data that remains unencrypted but is included in the authentication calculation. Examples include message types, protocol versions, or routing metadata. The receiver must supply the same AAD when decrypting, otherwise authentication fails.

What should an API do when AES-GCM authentication fails?

It should treat the operation as an unsuccessful decryption and avoid exposing unauthenticated plaintext. The failure should be translated into an appropriate application-level error without leaking sensitive cryptographic details. Logging should also avoid recording keys, plaintext, or other secrets. The exact response depends on the protocol, but authentication failure must not be silently ignored.