AEAD (Authenticated Encryption with Associated Data)

AEAD is a cipher interface, standardized in RFC 5116, that takes a key, a nonce, plaintext and optional associated data, and returns ciphertext plus an authentication tag. Decryption fails outright if a single bit of the ciphertext or the associated data has changed. Common AEAD algorithms are AES-GCM, ChaCha20-Poly1305 and AES-CCM.

Why it matters

Before AEAD, TLS protected records with a separate MAC followed by CBC encryption ("MAC-then-encrypt"). That construction produced a long line of padding-oracle and IV attacks, including BEAST, Lucky Thirteen and POODLE. AEAD removes the separate padding and MAC steps entirely. TLS 1.2 added AEAD suites as an option; TLS 1.3 allows nothing else and uses the record header as the associated data, so it is authenticated even though it is sent in clear.

Example

Two real TLS 1.2 suites that look similar but behave differently:

ECDHE-RSA-AES128-GCM-SHA256   AEAD (AES-GCM); SHA-256 is only used for key derivation
ECDHE-RSA-AES128-SHA256       AES-CBC with HMAC-SHA256, not AEAD

openssl ciphers -v marks AEAD suites with Mac=AEAD.

Common misconceptions

• "The SHA256 in a GCM suite name is the MAC." In AEAD suites the hash drives the PRF or HKDF; integrity comes from the AEAD tag.
• "AEAD makes nonce handling irrelevant." Reusing a nonce with the same key can break both confidentiality and authenticity of AES-GCM and ChaCha20-Poly1305. TLS derives each record's nonce from its sequence number to prevent reuse.
• "Any encryption also guarantees integrity." Unauthenticated modes such as CBC or CTR can be modified without detection; the authentication tag is what AEAD adds.