Authenticated Encryption

Authenticated encryption (commonly exposed as AEAD) protects encrypted data against disclosure and undetected modification. It can also authenticate visible associated data, while requiring careful nonce and key management.

Authenticated encryption is a symmetric-key technique that aims to provide confidentiality and integrity together. A successful decryption returns plaintext only after the ciphertext has passed authentication; modified or incorrectly keyed input should be rejected.

Many modern APIs expose authenticated encryption with associated data (AEAD). Alongside plaintext, the caller may provide associated data (AAD), such as a record identifier or protocol version. The AAD is authenticated but remains visible, so changing it causes verification to fail.

An AEAD operation typically takes a key, a nonce (also called an IV in some APIs), plaintext or ciphertext, and optional AAD. The nonce is not secret, but its required uniqueness or usage limits depend on the algorithm. With AES-GCM, nonce reuse under the same key is dangerous; use a reliable strategy to avoid it.

Treat authentication failure as a hard failure: do not use partial or unauthenticated plaintext. Keep keys secret, use a well-maintained library API, and avoid inventing your own encryption-and-MAC construction. AEAD does not hide message length or protect data outside the operation, such as application logic that accepts the wrong record for a valid ciphertext.

Key points

• AEAD provides confidentiality plus integrity/authenticity for encrypted data.
• AAD is integrity-protected but remains readable.
• A nonce is not secret; follow the algorithm's uniqueness and usage requirements.
• Reject authentication failures and never consume unauthenticated plaintext.
• Use a maintained library API rather than designing a custom composition.

Interview questions

What does authenticated encryption provide, and what is associated data?

AEAD combines encryption and authentication so a recipient can obtain plaintext only if verification succeeds. It also supports optional associated data, which is checked for integrity but remains in the clear. This prevents callers from accidentally treating modified ciphertext as valid plaintext, provided they handle authentication failure correctly.

Why does nonce management matter for AES-GCM?

A nonce need not be secret, but it must satisfy the algorithm's requirements and be available during decryption. For AES-GCM, reusing a nonce with the same key can undermine confidentiality and authentication. Systems should use a carefully designed counter or sufficiently large random nonces with collision risk assessed, and should rotate keys before usage limits are exceeded.

When would you use AAD in a backend service?

AAD is useful for visible fields whose integrity matters, such as a tenant identifier, schema version, or record type. The decrypting side must supply the exact AAD used when encrypting, and verification fails if it differs. Binding context this way can prevent a valid ciphertext from being accepted under a different record context, assuming the application chooses and checks that context correctly.

Why use an AEAD API instead of encryption alone?

Encryption alone does not necessarily detect malicious modification, depending on the mode and construction. A MAC authenticates data but does not hide it. AEAD exposes a single operation that provides both properties and gives callers a verification result before plaintext is accepted, reducing opportunities for composition mistakes.

Does AEAD prove who sent a message?

AEAD authenticates a ciphertext and its supplied AAD under a shared key, but it does not prove which individual holder of that key created the message. Every holder with encryption capability can produce a valid ciphertext. If public verifiability or signer attribution is required, a digital signature may be needed in addition to or instead of AEAD.