Authenticated Encryption with Associated Data (AEAD) Questions

Comprehensive understanding of AEAD modes (AES-GCM, ChaCha20-Poly1305, AES-SIV) and why authenticated encryption is essential rather than separate encryption and MAC. Common implementation pitfalls and how they compromise security. When different AEAD schemes are appropriate.

MediumTechnical

35 practiced

Explain why Poly1305 requires a one-time key per message. Describe how ChaCha20-Poly1305 ensures a fresh one-time key for each message, what happens if the one-time key (r or nonce-derived key) is reused across messages, and how that enables forgery or key-recovery attacks.

EasyTechnical

30 practiced

Compare AEAD modes with the classical approach of separate encryption and MAC. Describe the recommended composition (encrypt-then-MAC), why naive combinations (MAC-then-encrypt, encrypt-and-MAC) can be dangerous, and provide a concrete example attack that breaks a wrong composition. As a cryptographer, also discuss API and misuse-resistance trade-offs.

Sample Answer

**Brief answer / summary**Encrypt-then-MAC (EtM) is the recommended composition: first encrypt the plaintext, then compute a MAC over the ciphertext (and associated data). Verify the MAC before attempting to decrypt. AEAD schemes (e.g., AES-GCM, ChaCha20-Poly1305) provide this atomically and are preferred.

**Why EtM is recommended**- EtM gives strong guarantees: authenticity of ciphertext prevents chosen-ciphertext attacks before any decryption occurs, avoiding decryption-induced oracle leaks.- Formal results: IND-CPA encryption + EUF-CMA MAC composed as EtM yields INT-CTXT (ciphertext integrity) and often IND-CCA in practice.

**Why naive combos are dangerous**- MAC-then-encrypt (MtE): receiver decrypts then checks MAC. If decryption errors leak timing/padding/format differences, attacker gains an oracle (e.g., padding oracle / Lucky13 style attacks on TLS’s MtE).- Encrypt-and-MAC (E&M): separate tag over plaintext or ciphertext can allow malleability or tag-replay attacks; tags may leak structure if not tied to ciphertext.

**Concrete attack (MtE / TLS-style)**TLS prior to AEAD used MAC-then-encrypt with CBC. An attacker flips bits in a ciphertext block and submits modified records. Decryption produces either a padding error or a MAC failure — differing timing and error behavior allowed practical plaintext recovery (padding oracle / Lucky13). This demonstrates that performing MAC after decryption leaks information.

**API and misuse-resistance trade-offs**- Best practice: provide AEAD single-call APIs: encrypt(key, nonce, associated_data, plaintext) → (ciphertext, tag); decrypt(key, nonce, associated_data, ciphertext, tag) → plaintext or fail.- Trade-offs: - Usability vs flexibility: single high-level AEAD reduces misuse (prevents wrong composition) but limits custom schemes. - Nonce management: APIs must enforce/guide unique nonces (e.g., deterministic nonce derivation or explicit checks); nonce misuse remains a common pitfall. - Side-channels: constant-time verification, early MAC check to avoid decryption on failure.- Recommendation: ship AEAD primitives, constant-time APIs, safe nonce helpers, and clear docs to minimize developer mistakes.

EasyTechnical

32 practiced

Explain in technical detail why nonce reuse in AES-GCM is catastrophic. Describe the algebraic reasons including keystream reuse from CTR and GHASH linearity, what an attacker can learn (plaintext XORs, forgery capability, possible leakage of the GHASH key H), and outline concrete steps an attacker uses after observing two ciphertexts with the same nonce.

Sample Answer

**High-level summary**Nonce reuse in AES‑GCM is catastrophic because it simultaneously breaks confidentiality (CTR keystream reuse) and authenticity (GHASH linearity). Both failures are algebraic and easily exploited: reuse yields plaintext XORs, allows tag algebra to be manipulated, and with enough samples can reveal the GHASH field key H or let an attacker forge tags for messages under the same nonce.

**Algebraic building blocks**- CTR keystream: ciphertext blocks Ci = Pi XOR Si where Si = E_K(ctr_i). If nonce/IV repeats then all Si sequences repeat → keystream reuse.- GHASH: GHASH(H, X) is a linear function over the GF(2^128) field with H = E_K(0) (the GHASH key). Concretely GHASH processes 128‑bit blocks Xi and computes a polynomial evaluation; algebraically:

text

GHASH(H, X) = Σ Xi · H^{n-i+1}  (field multiplication and addition in GF(2^128))

Plain-English: GHASH is linear in the Xi when H is fixed.

Tag formation: Tag T = E_K(ctr_0) XOR GHASH(H, A || C || lengths). If same nonce, E_K(ctr_0) is identical.

**What attacker learns**- Plaintext XORs: From two ciphertexts C1, C2 with same nonce, - C1 XOR C2 = (P1 XOR S) XOR (P2 XOR S) = P1 XOR P2. So attacker immediately gets P1 XOR P2.- Tag algebra and forgery: Let T1, T2 be tags. Since E_K(ctr_0) cancels, - T1 XOR T2 = GHASH(H, X1) XOR GHASH(H, X2) = GHASH(H, X1 XOR X2). The attacker therefore obtains one linear GHASH equation relating H and the known block differences.- GHASH key leakage: With multiple reused nonces and many observed (Xi, Ti) pairs, the attacker obtains linear equations in powers of H and can solve (via linear algebra or polynomial solving) to recover H, enabling full forgery capability for that nonce (and potentially beyond).- Full plaintext recovery: If the attacker ever learns one plaintext for that nonce (e.g., known header), they recover the keystream S = C XOR P and can decrypt all other ciphertexts with the same nonce.

**Concrete attacker steps after observing two ciphertexts (same nonce)**1. Compute P1 XOR P2 = C1 XOR C2. Inspect this for structure or known fields to recover one plaintext (e.g., known protocol headers). If a guess/corresponding-plaintext is found, recover both P1 and P2 fully via keystream.2. Compute ΔT = T1 XOR T2 = GHASH(H, X1 XOR X2). From known XΔ = X1 XOR X2, you have a GHASH output for that input.3. Collect more reused-nonce triples (Xi, Ti) to form a system of linear equations in H (or in field powers of H). Solve for H (practical with enough independent equations).4. Once H is known, attacker can compute GHASH(H, X') for any chosen (A', C', lengths), and then compute the correct tag for a forged ciphertext under the same E_K(ctr_0) if E_K(ctr_0) is known — or combine with observed tags to cancel E_K(ctr_0) and produce valid tags for new messages under that nonce.5. If E_K(ctr_0) is unknown but you have one observed (C, T) and you can set C' so GHASH(H, X') = GHASH(H, X) XOR Δ, then T' = T XOR Δ yields a valid tag (uses GHASH linearity). This enables existential forgeries.

**Why this is catastrophic**- Confidentiality: immediate leakage of plaintext relations; single known plaintext yields many plaintexts.- Integrity: attacker can produce valid tags or eventually recover H → full forgery.- State reuse scope: even one reused nonce compromises all messages that reuse it; multiple reused nonces accelerate H recovery.

Prevent this by unique nonces per key (or deterministic nonce schemes proven safe), and fail closed if a nonce repeats.

MediumTechnical

35 practiced

You are reviewing C code using OpenSSL EVP APIs that attempts to construct a 64-bit random prefix and a 64-bit counter to form a 128-bit IV but then passes that 16-byte IV to AES-GCM as though it were a correct nonce. Here is the snippet:

uint8_t iv[16];
memcpy(iv, random_prefix, 8);
memcpy(iv+8, &counter, 8); // counter is uint64_t
EVP_EncryptInit_ex(ctx, EVP_aes_128_gcm(), NULL, key, iv);

Identify the issues with this approach (including RFC guidance about IV length for GCM), possible attacks or inefficiencies, and propose a correct and robust IV derivation and management strategy compliant with standards.

Sample Answer

**Short answer / issues identified**

- GCM expects a 96-bit (12 byte) nonce as the recommended (and most efficient) IV; if you pass a non-96-bit IV the algorithm must GHASH the IV to derive J0 per NIST SP 800-38D — slower and error-prone.- The snippet builds a 128-bit IV and passes it without setting IV length; OpenSSL will not implicitly do the GHASH derivation for you unless you correctly set the IV length and use the API as intended. This likely results in incorrect IV interpretation or truncation.- memcpy(&counter, iv+8, 8) introduces endianness/aliasing/alignment issues; different platforms order the counter differently leading to duplicate nonces across peers.- Using a random_prefix + counter without careful uniqueness guarantees (persisting counter across restarts, atomicity, overflow handling) risks nonce reuse — catastrophic for AES-GCM (auth key recovery / forgery).- 128-bit IVs for GCM are non-standard and can cause interoperability and security pitfalls.

**Attacks / inefficiencies**- Reuse of IV with same key allows tag forgery and plaintext/recovery attacks in GCM.- Non-96-bit IVs force GHASH(IV) every call; performance and side-channel surface increases.- Endianness mistakes can cause accidental reuse and predictable nonces enabling forgery or plaintext-correlation.

**Correct, robust strategy (standards-compliant)**

- Use 96-bit (12-byte) nonces whenever possible (NIST SP 800-38D / RFCs that recommend 12 bytes for AES-GCM).- Construct nonce = per-key fixed salt (4 bytes) || per-message counter (8 bytes) or: 12 bytes = 4B random/session || 8B monotonic counter. Ensure counter: - Starts at a defined non-zero base, - Is monotonic and atomic, - Is persisted across restarts or the salt is unique per boot.- Use network (big-endian) byte order when encoding integers into the nonce.- Before calling EVP_EncryptInit_ex set IV length explicitly and pass the exact 12-byte IV: - EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_SET_IVLEN, 12, NULL);- Consider deriving per-message nonces with an HKDF/AES-CTR keyed derivation from a master salt so nonce uniqueness is cryptographically ensured.

Example (safe pattern):

uint8_t iv[12];
uint32_t salt = session_salt;          // 4 bytes unique per key/session
uint64_t seq = htobe64(next_sequence); // big-endian 8-byte counter
memcpy(iv, &salt, 4);
memcpy(iv+4, &seq, 8);

EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_SET_IVLEN, 12, NULL);
EVP_EncryptInit_ex(ctx, EVP_aes_128_gcm(), NULL, key, iv);

**Operational notes / best practices**- Never rely on random-prefix reuse; generate a fresh random salt per key.- Detect and prevent counter wraparound; rekey before overflow.- If non-96-bit IVs are unavoidable, explicitly compute J0 per SP 800-38D (GHASH) and use it correctly — but prefer 96-bit to avoid GHASH-on-IV.- Add unit tests covering endianness, restart behavior, and IV uniqueness.

HardTechnical

31 practiced

You are evaluating a hardware AES-GCM accelerator. Describe the cryptanalytic tests, functional unit tests, and microarchitectural security evaluations you would require before approving it for production. Include tests for IV handling, concurrent session isolation, side-channel leakage (power, EM), fault injection resilience, and integration with HSM key management.

Sample Answer

**Overview / acceptance criteria**I would require cryptanalytic robustness, deterministic functional correctness, and microarchitectural resilience to side channels and faults, plus secure HSM integration. Approval requires passing all test categories and documented mitigations for any residual risk.

**Cryptanalytic tests**- Verify AES-GCM tag correctness across full nonce/tag space sampling (Monte Carlo + targeted patterns).- Test for IV reuse detection/handling; confirm deterministic failure or policy enforcement when IV collisions occur.- Check GHASH collision resistance and polynomial wrap/overflow handling; run differential and related-key-style tests to detect nonce/associated-data misuse.- Perform distinguishing attacks: entropy tests on keystreams, statistical tests (NIST STS, Dieharder), and targeted tests for weak keys.

**Functional unit tests**- Unit tests: AES core (all 256 AES test vectors), GCTR, GHASH, counter incrementing (endianness, overflow).- Concurrency: stress with thousands of concurrent sessions, interleaved contexts, and abrupt session teardown; verify zeroization of session state.- IV handling: enforce/validate IV length variants, tag truncation behavior, and explicit rejection of nonstandard IVs.- Fault injection simulation at microcode boundaries; verify error codes and no silent failures.

**Microarchitectural & side-channel**- Power & EM: CPA/Template attacks across multiple process corners and caches; ensure masked S-boxes or gating reduce leakage to >50 dB margin.- Timing: constant-time verification for tag checks, counter update, and key-dependent branches.- Cache & speculative: test for Flush+Reload, Prime+Probe, and speculative-execution leakage; ensure branchless design or fences where needed.

**Fault injection resilience**- Laser/voltage/frequency fault campaigns to induce bit flips; verify corrupted outputs are detected (MAC fails) and that failures don't leak key material.- Implement and test redundancy checks, integrity tags for internal state, and fail-stop behaviors.

**HSM / key management integration**- Validate KMIP/PKCS#11 flows: key import, attributes (usage, extractable=false), and wrapping/unwrapping with HSM master keys.- Ensure key handle isolation: accelerator should never expose raw key material; test man-in-the-middle on key provisioning paths.- Audit & logging: immutable event records for key lifecycle and crypto operations.

**Metrics & gating**- Define quantitative pass thresholds: leakage margins, failure rates under fault injection, concurrency isolation tests, and crypto test coverage. Reject until fixes proven by re-test and independent audit.

Unlock Full Question Bank

Get access to hundreds of Authenticated Encryption with Associated Data (AEAD) interview questions and detailed answers.

Join thousands of developers preparing for their dream job.