Three generic composition methods exist: Encrypt-then-MAC, MAC-then-Encrypt, Encrypt-and-MAC. Only one is generically secure. Which, and why do the others fail?
Think about your answer, then reveal below.
Model answer: Encrypt-then-MAC is the only generically secure composition. The MAC covers the ciphertext, so the verifier can reject tampered ciphertexts without decrypting — no information about the plaintext leaks through decryption errors. MAC-then-Encrypt computes MAC(m), then encrypts (m || MAC(m)). The receiver must decrypt before verifying the MAC, and differences in decryption error behavior (e.g., padding oracle attacks in CBC mode) can leak plaintext byte by byte. Encrypt-and-MAC encrypts m and separately MACs m (the plaintext). The MAC tag may leak information about m since MAC is not required to hide its input.
This is one of the most practically important results in applied cryptography. TLS up through version 1.2 used MAC-then-Encrypt, leading to the BEAST (2011), Lucky 13 (2013), and POODLE (2014) attacks that exploited padding oracle behavior. TLS 1.3 mandates AEAD constructions (GCM, ChaCha20-Poly1305) that integrate encryption and authentication, eliminating composition errors entirely.
Question 2 Multiple Choice
A developer implements AES-GCM correctly but reuses a nonce for two different messages under the same key. How severe is this failure?
AConfidentiality is mildly reduced but authentication remains intact
BCatastrophic — nonce reuse in GCM breaks both confidentiality (same keystream XORed with different plaintexts, revealing their XOR) and authenticity (the authentication key H can be recovered from two ciphertexts with the same nonce, enabling universal forgeries on all past and future messages)
COnly the two affected messages are compromised; other messages remain secure
DGCM detects and rejects nonce reuse automatically
GCM nonce reuse is uniquely catastrophic because it breaks not just confidentiality but also authentication — permanently. The authentication tag is a polynomial evaluation at a secret point H. Two tags with the same nonce reveal H (solve the polynomial equation). Once H is known, the attacker can forge valid tags for any ciphertext. This is why nonce-misuse resistant schemes like SIV (Synthetic IV) and GCM-SIV exist: they degrade more gracefully under nonce reuse, losing only indistinguishability of repeated messages while preserving authentication.
Question 3 Multiple Choice
ChaCha20-Poly1305 was designed as an alternative to AES-GCM for platforms without hardware AES support. What are its advantages?
AChaCha20-Poly1305 provides stronger security guarantees than AES-GCM
BChaCha20 uses only ARX operations (add, rotate, XOR) that execute in constant time on all CPUs without special instructions, avoiding timing side channels that affect software AES implementations. Poly1305 is a similarly simple polynomial MAC. Together they provide excellent performance on mobile/embedded devices lacking AES-NI instructions
CChaCha20-Poly1305 supports larger message sizes than GCM
DPoly1305 provides stronger authentication than GHASH
On CPUs with AES-NI (hardware AES acceleration), AES-GCM is typically faster. On CPUs without it (many ARM chips, older x86), software AES is slow and vulnerable to cache-timing attacks. ChaCha20-Poly1305's ARX operations are naturally constant-time and fast on all architectures. This is why TLS 1.3 includes both: servers select AES-GCM when AES-NI is available and ChaCha20-Poly1305 otherwise. Google deployed ChaCha20-Poly1305 for HTTPS to Android devices, where AES-NI is rare.
Question 4 True / False
Standalone encryption (encryption without authentication) should never be used in modern systems.
TTrue
FFalse
Answer: True
This is now the consensus of the cryptographic community. Unauthenticated encryption is malleable — attackers can modify ciphertexts to produce controlled changes in the plaintext, and the recipient has no way to detect tampering. Every major attack on TLS encryption (BEAST, Lucky 13, POODLE, Bleichenbacher) exploited the lack of early authentication. Modern protocols (TLS 1.3, Signal, WireGuard) mandate AEAD, and all NIST and IETF guidelines treat standalone encryption as deprecated.
Question 5 Short Answer
AEAD's 'associated data' (AD) is authenticated but not encrypted. Give an example of data that should be associated data rather than part of the encrypted payload.
Think about your answer, then reveal below.
Model answer: Network packet headers are the classic example. In a TLS record, the header specifies the protocol version, content type, and length — routing information that network infrastructure needs to process the packet. This data must be authenticated (to prevent an attacker from changing the content type or length without detection) but not encrypted (because routers and load balancers need to read it for packet handling). AEAD binds the header to the ciphertext cryptographically: any modification to either the header or the encrypted payload invalidates the authentication tag.
Other examples include database row IDs (authenticate which row the ciphertext belongs to, preventing row-swapping attacks), message sequence numbers (prevent reordering attacks), and algorithm identifiers (prevent algorithm-downgrade attacks). The AD mechanism ensures that context surrounding the ciphertext is tamper-proof even when it's visible.