Authenticated Encryption

AE schemes merge two traditionally separate operations—encryption and message authentication—into a single primitive. This prevents catastrophic implementation errors like MAC-then-Encrypt padding oracle attacks (e.g., Lucky13). The scheme ensures that an adversary cannot decrypt the message without the key, and any modification to the ciphertext causes a decryption failure rather than leaking plaintext information.

The integrity property ensures that an adversary cannot forge a valid ciphertext that will decrypt successfully. This is formalized as INT-CTXT security (Integrity of Ciphertexts). Without this property, systems are vulnerable to chosen-ciphertext attacks (CCA), where an attacker modifies a ciphertext and observes the system's reaction to learn about the plaintext. AE guarantees that any forged ciphertext is rejected with overwhelming probability.

Modern protocols use AEAD to bind ciphertexts to contextual metadata that is authenticated but not encrypted. This prevents confusion attacks where a valid ciphertext is replayed in a different context.

• Associated Data (AD): Unencrypted metadata (e.g., packet headers, session IDs, protocol version numbers).
• Binding: The authentication tag covers both the ciphertext and the AD, ensuring the ciphertext cannot be detached from its intended context.
• Example: TLS 1.3 uses AEAD to bind encrypted records to sequence numbers and content types.

Standard AE schemes like AES-GCM catastrophically fail if a nonce (initialization vector) is reused with the same key—an attacker can XOR two ciphertexts to cancel the authentication key and forge messages. Misuse-Resistant AE (MRAE) schemes like AES-GCM-SIV mitigate this:

• Synthetic IV (SIV): The nonce is derived deterministically from the plaintext and associated data using a PRF.
• Safety Net: If a nonce repeats, the only leakage is that identical plaintexts produce identical ciphertexts—authentication keys are never exposed.

When a dedicated AE primitive is unavailable, the only generically secure composition is Encrypt-then-MAC:

1. Encrypt the plaintext with a symmetric cipher to produce ciphertext.
2. Compute a MAC over the ciphertext (and associated data).
3. Append the MAC tag to the ciphertext.

This ensures that the system never decrypts unauthenticated data, preventing padding oracle and timing side-channel attacks. Other compositions (MAC-then-Encrypt, Encrypt-and-MAC) have known theoretical weaknesses and practical vulnerabilities.

AE provides IND-CCA2 security (Indistinguishability under Adaptive Chosen-Ciphertext Attack). In this model:

• The adversary has access to a decryption oracle for any ciphertext except the challenge.
• The adversary cannot distinguish which of two plaintexts was encrypted.

This models real-world scenarios where an attacker can send modified ciphertexts to a server and observe error messages or timing differences. AE ensures that the decryption oracle is useless—every forged ciphertext is rejected with a uniform error, leaking no plaintext information.

The foundational primitive where both sender and receiver share a single secret key. Authenticated encryption extends basic symmetric ciphers by integrating integrity checks. AES (Advanced Encryption Standard) in CBC or CTR mode provides confidentiality but requires a separate MAC for authentication.

• Stream ciphers like ChaCha20 encrypt data bit-by-bit
• Block ciphers operate on fixed-size blocks (128-bit for AES)
• Without authentication, ciphertexts are malleable — attackers can modify them undetectably

A short piece of information used to authenticate a message and verify its integrity. MACs protect against chosen-ciphertext attacks by ensuring ciphertexts cannot be forged. Common constructions include:

• HMAC (Hash-based MAC) using SHA-256 or SHA-3
• CBC-MAC for block cipher modes
• Poly1305 — a fast, software-optimized MAC often paired with ChaCha20

A ciphertext without a valid MAC must be rejected immediately to prevent padding oracle attacks.

Authenticated Encryption with Associated Data binds ciphertext to contextual metadata (e.g., session IDs, packet headers) that is authenticated but not encrypted. Modern constructions:

• AES-GCM — Galois/Counter Mode, widely used in TLS 1.3, leverages hardware AES-NI acceleration
• ChaCha20-Poly1305 — preferred on mobile and ARM devices without AES instructions
• AES-OCB — offset codebook mode, patent-encumbered but highly efficient

AEAD modes prevent attackers from replaying ciphertexts in different contexts.

Cryptographic functions that derive one or more secret keys from a master secret, password, or shared Diffie-Hellman output. Essential for generating the distinct encryption and MAC keys required by authenticated encryption schemes.

• HKDF (HMAC-based Key Derivation Function) — standard in TLS 1.3 and Signal Protocol
• PBKDF2 and Argon2 — for password-based key derivation with brute-force resistance
• Key separation prevents cross-protocol attacks: never reuse the same key for encryption and authentication

A nonce (number used once) is a critical input to AEAD ciphers that must never repeat under the same key. Nonce reuse catastrophically breaks confidentiality in AES-GCM by revealing the authentication key.

• Counter-based nonces: simple sequential integers — vulnerable to reset
• Random nonces: 96-bit random values — safe with low collision probability
• Synthetic IVs: derive nonce from the plaintext itself (e.g., AES-GCM-SIV) — misuse-resistant

Proper nonce generation is the most common implementation pitfall in authenticated encryption deployments.

The only generically secure composition order when combining separate encryption and MAC primitives. The plaintext is encrypted first, then the MAC is computed over the ciphertext (not the plaintext).

• MAC-then-Encrypt (used in older TLS) is vulnerable to padding oracle attacks
• Encrypt-and-MAC leaks equality information about plaintexts
• Modern libraries like libsodium enforce Encrypt-then-MAC by default via crypto_secretbox

Always prefer dedicated AEAD constructions over manual composition to avoid ordering errors.