AEAD

An AEAD takes a key, a nonce, a plaintext and optional associated data (AD), and returns ciphertext plus an authentication tag. Decryption either returns the original plaintext or fails outright. There is no partially valid output, which is the point: unauthenticated encryption (CBC, CTR on their own) lets an attacker flip bits or run padding-oracle attacks.

The associated data is authenticated but not encrypted. Use it to bind context to the ciphertext: a record ID, a tenant ID, a key version, a protocol header. If someone copies tenant A's ciphertext into tenant B's row, decryption fails because the AD no longer matches.

The standard choices are AES-GCM and ChaCha20-Poly1305; both are in TLS 1.3, which only permits AEAD suites. The common failure is not the algorithm but the nonce: reusing a nonce under the same key breaks confidentiality and, for GCM and Poly1305, lets an attacker forge tags. Standard AEADs are also not key-committing, which matters in multi-key designs.

In interviews, "use an AEAD, never roll your own encrypt-then-MAC" is the expected baseline, followed by how you generate nonces and what you put in the AD.