CS 161, Lesson 24, in 50 slides. It explains why a MAC gives no confidentiality, in section 8.6, then combines encryption with a MAC and compares the two orders in section 8.7: encrypt-then-MAC against MAC-then-encrypt, with the padding-oracle break that the latter allows. It covers authenticated encryption with associated data in section 8.8, and AES-GCM together with its catastrophic failure under nonce reuse. It is anchored to textbook sections 8.6 to 8.8.
Subject: Computer Security · 86 slides · applied lesson
Open the interactive version of this deck · Homework for this lesson
Title
CS 161 · Lesson 24 of 45
a MAC hides nothing · encrypt-then-MAC vs MAC-then-encrypt · AEAD & associated data · AES-GCM and the nonce-reuse cliff
Objectives
Warm-up
Discussion prompt
Before we open L24 · Authenticated Encryption & AEAD: without looking back, what was the main idea of L23 · Message Authentication Codes: EUF-CMA, AES-EMAC, HMAC, and what could you do by the end of it that you could not do before?
Hint: One sentence for the idea, one for the skill. If the second one is blank, that is the part to revisit.
Answer:
CS 161, Lesson 23, in 51 slides. It explains what a MAC is and what it guarantees, in sections 8.1 and 8.2, then defines unforgeability through the EUF-CMA forgery game in section 8.3. It covers the AES-EMAC CBC-MAC construction and its two-key final step in section 8.4, and HMAC, built from NMAC with the ipad and opad key transform, in section 8.5 - including why the naive Hash(K||M) is forgeable. It is anchored to textbook sections 8.1 to 8.5.
Concept
L23 built MACs — integrity and authenticity. But a MAC alone says nothing about secrecy. Today we combine secrecy and integrity into one safe primitive.
Matching
Match the pairs
From Three questions this lesson answers — match each one to what it actually does. The descriptions have been shuffled.
Why: Does a MAC hide M?, How to get both?, One primitive for both? are easy to tell apart while they are sitting next to their descriptions and much harder afterwards, which is what this checks.
Section
Part 1 · §8.6 MACs are not confidential
Concept
In L23, Alice sent Bob a message M together with a tag T = MAC(K, M). Bob recomputes the tag and checks it matches — that proves M was not tampered with and really came from someone holding K.
But look at what actually went over the wire: M itself, in plaintext, alongside the tag. A MAC was never trying to hide M — it only certifies M. Integrity is not confidentiality.
Counterexample
Discussion prompt
In L23, Alice sent Bob a message M together with a tag T = MAC(K, M). Bob recomputes the tag and checks it matches — that proves M was not tampered with and really came from someone holding K.
That is stated as though it always holds. Do one of two things: produce a case where it fails, or say precisely what rules such a case out. "It just does" is not on the menu.
Hint: Hunt at the extremes first — zero, one, negative, empty, equal. If every extreme survives, the reason they survive is the proof.
Concept
MAC (message authentication code) — A keyed function T = F(K, M) that gives integrity and authenticity: an attacker who does not know K cannot forge a valid (M, T) pair. It promises unforgeability — and nothing about secrecy.
Nothing in the definition of a secure MAC says F(K,M) hides M. The tag may leak partial — or total — information about the message and still be perfectly unforgeable.
There is also no general 'decrypting' a MAC: Alice and Bob both run the SAME algorithm F to verify. (Some MACs CAN be reversed with the key — e.g. a single-block AES-based MAC — but that is incidental, not the point.)
Analogy
Discussion prompt
Explain §8.6 What a MAC does and does NOT promise by analogy to something with no Computer Security in it at all — a queue, a recipe, a map, a bank balance, whatever fits. Then say where your analogy breaks.
Hint: An analogy that never breaks is not an analogy, it is the same idea wearing a hat. Find the seam — that is the part that is actually new.
Answer:
Nothing in the definition of a secure MAC says F(K,M) hides M. The tag may leak partial — or total — information about the message and still be perfectly unforgeable.
Intuition
Think of a MAC as a tamper-evident seal on a postcard. The seal proves nobody altered the message and that it came from the right sender — but the postcard text is still right there for anyone to read.
A seal that is impossible to forge tells you nothing about whether the contents are visible. Unforgeability (integrity) and invisibility (confidentiality) are orthogonal goals.
Ask yourself: if I could make the seal carry a perfect photocopy of the whole postcard and it were still unforgeable, would it be any less of a 'secure MAC'? (No — which is exactly the counterexample we build next.)
Explain it
Discussion prompt
Explain §8.6 'Unforgeable' and 'hidden' are different jobs to a student a year behind you. No notation, no jargon they have not met — and it still has to be true.
Hint: If your explanation needs a symbol they have never seen, you are describing the notation rather than the idea.
Answer:
A seal that is impossible to forge tells you nothing about whether the contents are visible. Unforgeability (integrity) and invisibility (confidentiality) are orthogonal goals.
Concept
To prove 'secure MAC' implies nothing about secrecy, we don't argue in words — we exhibit a single function that is provably a secure MAC and yet provably leaks the message.
One example that satisfies the MAC definition while broadcasting M settles it: the definition cannot possibly be promising confidentiality, or such a function couldn't exist. That function is F′, next.
Concept
Take ANY secure MAC F and define a new function F′ that appends the plaintext to the tag:
\[ F'(K, M) = F(K, M) \,\Vert\, M \]
Here ‖ is concatenation. F′ outputs the original valid tag followed by the entire message. It obviously leaks M — yet, as we'll prove, it is still a perfectly secure MAC.
Ranking
Put in order
Put the moves of §8.6 F′ is still unforgeable — but leaks everything into the order they have to happen.
Why: These are the moves of the worked example in the order it makes them, and each one is set up by the one before it. This is our only hypothesis — F meets the standard MAC security definition (existential unforgeability under chosen-message attack).
Worked example
Assume F is a secure MAC: no efficient attacker can forge a valid (M, F(K,M)) pair without K
Why: This is our only hypothesis — F meets the standard MAC security definition (existential unforgeability under chosen-message attack).
Suppose an attacker could forge F′ on a NEW message M: a valid F′(K, M) = F(K, M) ‖ M
Why: A forgery against F′ is a tag the attacker produces for a message it never queried.
Strip off the M* suffix — the prefix is exactly F(K, M*), a forgery against F
Why: F′ just appends M, so the first part of any valid F′ tag is a valid F tag. Forging F′ would forge F — contradicting our assumption.
\[ \text{forge } F' \;\Rightarrow\; \text{forge } F \quad(\text{impossible}) \]
Note F′ leaks M in the clear: the suffix IS the entire plaintext
Why: Anyone who sees the tag F′(K, M) reads M directly off the end — zero confidentiality.
Verify the point: F′ is a secure MAC (unforgeable) AND leaks the whole message
Why: §8.6: 'secure MAC' constrains forgery only. It says nothing about secrecy — a MAC can broadcast the plaintext and still pass.
Notation
Annotate
From §8.6 F′ is still unforgeable — but leaks everything — read this one piece at a time. What is each part doing?
On: \( \text{forge } F' \;\Rightarrow\; \text{forge } F \quad(\text{impossible}) \)
Step zero
Discussion prompt
§8.6 A concrete F′: the tag broadcasts the message — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.
Hint: It starts with: Let M = 1011 and suppose the underlying MAC gives F(K, M) = 0110
Answer:
Worked example
Let M = 1011 and suppose the underlying MAC gives F(K, M) = 0110
Why: Any secure MAC F produces some fixed-length tag; the exact bits don't matter — what matters is what F′ does with them.
Form the F′ output by concatenating the tag with the plaintext
Why: F′ appends M to the right of the genuine tag — the ‖ operator just glues the two bit-strings together.
\[ F'(K, M) = 0110 \,\Vert\, 1011 = 0110\,1011 \]
Read the plaintext straight off the suffix of the tag
Why: Anyone seeing 01101011 takes the last 4 bits — 1011 — and recovers M with no key. The 'tag' literally carries the message.
Verify both claims hold: still unforgeable (prefix is a real F tag), yet fully leaks M
Why: §8.6: confidentiality and unforgeability are independent — this single output is the proof made concrete.
Blank canvas
Draw it
Draw what §8.6 A concrete F′: the tag broadcasts the message just did — the shape of it, not the line-by-line working. One picture, labels only where you need them. Then check it against the steps: anything you could not draw is a step you followed rather than understood.
Concept
In practice HMAC and block-cipher-based MACs (CBC-MAC, CMAC) happen NOT to reveal the message — their output looks random. But that is a property of those specific constructions, not something the MAC definition guarantees.
The lesson stands: never rely on a MAC for secrecy. If you need the message hidden, you must encrypt it. A tag is a certificate, not a lockbox.
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'The message is MAC'd, so it's protected — an eavesdropper can't read it.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: Wrong — and this is THE recurring error of the unit.
A student: what does a MAC actually buy me?
Why: Wrong — and this is THE recurring error of the unit. A MAC gives integrity/authenticity only; the message often rides in plaintext, and even F′ shows a MAC can carry M itself. Integrity ≠ confidentiality.
Trap
A student: 'The message is MAC'd, so it's protected — an eavesdropper can't read it.'
\[ M \,\Vert\, \text{MAC}(K,M) \;\stackrel{?}{\Rightarrow}\; M \text{ is hidden} \]
Equate 'has a MAC' with 'confidential'
Why: Wrong — and this is THE recurring error of the unit. A MAC gives integrity/authenticity only; the message often rides in plaintext, and even F′ shows a MAC can carry M itself. Integrity ≠ confidentiality.
A student: what does a MAC actually buy me?
\[ \text{MAC} \Rightarrow \text{integrity + authenticity, NOT secrecy} \]
Read a MAC as a tamper-evident seal, then ENCRYPT for secrecy
Why: §8.6: to hide M you must encrypt it; to detect tampering you add a MAC. They are separate goals — combine an IND-CPA cipher AND a MAC to get both.
Section
Part 2 · §8.7 the two orders
Concept
Real protocols need confidentiality AND integrity at the same time: Eve must not be able to read the message, and Mallory must not be able to alter it undetected.
We have the parts: an IND-CPA encryption scheme Enc (L20–L21) and an unforgeable MAC (L23). The question is how to combine them — and the ORDER matters more than you'd expect.
Concept
Encrypt-then-MAC — Encrypt the message, then compute the MAC over the resulting CIPHERTEXT. Send the ciphertext and that tag. The MAC authenticates what actually travels on the wire.
\[ \text{send: } C = \text{Enc}_{K_1}(M), \quad T = \text{MAC}_{K_2}(C) \]
The receiver checks the tag on C first; only if it verifies does it bother to decrypt. Tampering is caught before decryption ever runs.
Definition probe
Sort into buckets
Every line below is part of the definition of MAC (message authentication code) or of Encrypt-then-MAC — one or the other, never both. Put each where it belongs.
Intuition
The MAC over C gives ciphertext integrity: any change to the bytes on the wire is detected by the tag check — without ever decrypting attacker-controlled input.
And nothing leaks: C already hides M (it's IND-CPA), and the tag is computed over C, so at worst the tag reveals something about the ciphertext — which already reveals nothing about the plaintext.
Ask yourself: where does the receiver's decryption code ever touch unverified attacker bytes? (It doesn't — the tag gate stops bad input at the door.)
Step zero
Discussion prompt
§8.7 Encrypt-then-MAC, step by step — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.
Hint: It starts with: Sender: encrypt the plaintext under the encryption key K1
Answer:
Worked example
Sender: encrypt the plaintext under the encryption key K1
Why: First produce the ciphertext that will actually travel on the wire; nothing is authenticated yet.
\[ C = \text{Enc}_{K_1}(M) \]
Sender: compute the MAC over the CIPHERTEXT under the MAC key K2, and send (C, T)
Why: The tag covers C — the exact bytes on the wire — using an independent key K2.
\[ T = \text{MAC}_{K_2}(C); \quad \text{send } (C, T) \]
Receiver: recompute MAC_{K2}(C) and check it equals T — if not, REJECT without decrypting
Why: The tag gate runs first; tampered ciphertext is dropped before the decryption routine ever touches it.
Verify: only on a passing tag does the receiver compute M = Dec_{K1}(C)
Why: §8.7: verify-then-decrypt gives ciphertext integrity and keeps attacker bytes away from the decrypt routine.
Translation
\( T = \text{MAC}_{K_2}(C); \quad \text{send } (C, T) \)
Draw it
Translate both ways. First write the expression above as a sentence with no symbols in it at all. Then cover it, and write your sentence back as notation. If the two versions disagree, the disagreement is the thing to fix.
Concept
MAC-then-encrypt — Compute the MAC over the PLAINTEXT, append it to the message, and encrypt the whole thing. The tag is hidden inside the ciphertext and only revealed after decryption.
\[ \text{send: } C = \text{Enc}_{K_1}\big(M \,\Vert\, \text{MAC}_{K_2}(M)\big) \]
Now the receiver has no way to check the tag without first decrypting — and the bytes it decrypts are whatever the attacker put on the wire. That ordering is the seed of a real attack.
Intuition
With MAC-then-encrypt there is no ciphertext integrity. To learn whether a message is authentic, the receiver must run decryption on raw, attacker-chosen bytes — then look inside for a valid tag.
Running your decryption routine on arbitrary input is dangerous: the decryption process itself can leak information through timing, error messages, or padding checks — a side channel.
Ask yourself: in encrypt-then-MAC, does the attacker ever get the decrypt routine to run on chosen bytes? (No — the tag check rejects them first. That's the whole difference.)
Ranking
Put in order
Put the moves of §8.7 The padding-oracle attack on MAC-then-encrypt into the order they have to happen.
Why: These are the moves of the worked example in the order it makes them, and each one is set up by the one before it. CBC needs the plaintext padded to a whole number of blocks; the receiver must check that padding is well-formed AFTER decrypting — before it can find and verify the MAC.
Worked example
Setup: a real TLS implementation used MAC-then-encrypt with CBC-mode block encryption
Why: CBC needs the plaintext padded to a whole number of blocks; the receiver must check that padding is well-formed AFTER decrypting — before it can find and verify the MAC.
Mallory submits a tampered ciphertext; the receiver decrypts it (no tag gate stops her)
Why: Because the MAC is inside the ciphertext, the receiver has to decrypt the attacker's bytes first — exactly the decrypt-before-verify hazard.
The receiver reacts differently depending on whether the PADDING was valid
Why: A padding-error path and a MAC-error path took different times / returned different errors — a side channel leaking one bit: 'was the padding valid?'
Mallory uses that one-bit oracle, ciphertext by ciphertext, to recover the plaintext
Why: Classic padding-oracle math: tweak a byte, watch the padding signal, and peel off the plaintext one byte at a time — no key ever needed.
Verify the conclusion: MAC-then-encrypt enabled a real decryption attack; encrypt-then-MAC would have blocked it
Why: §8.7: tagging the ciphertext means the bad input is rejected before decryption — no padding oracle. This is why encrypt-then-MAC is the better order.
Concept
In BOTH constructions, the encryption key and the MAC key must be independent: K1 ≠ K2. Never feed one shared key to both the cipher and the MAC.
\[ K_1 \;(\text{encrypt}) \;\neq\; K_2 \;(\text{MAC}) \]
Reusing one key for both opens a whole class of attacks: the security proofs assume the two keys are independent, and interactions between a cipher and a MAC sharing a key can collapse both guarantees.
Pattern
Predict first
The table runs: MAC computed over | the ciphertext C | the plaintext M · Ciphertext integrity? | yes | no · Decrypt attacker bytes before verify? | no — tag gate first | yes — must decrypt to find tag · Real-world break | none (the recommended order) | padding-oracle attack on a TLS impl
In §8.7 The two orders, side by side, given the rows so far: what is the next one — the row where Property is Two independent keys??
Correct: Two independent keys? | required (K1 ≠ K2) | required (K1 ≠ K2)
| Property | Encrypt-then-MAC | MAC-then-encrypt |
|---|---|---|
| MAC computed over | the ciphertext C | the plaintext M |
| Ciphertext integrity? | yes | no |
| Decrypt attacker bytes before verify? | no — tag gate first | yes — must decrypt to find tag |
| Real-world break | none (the recommended order) | padding-oracle attack on a TLS impl |
| Two independent keys? | required (K1 ≠ K2) | required (K1 ≠ K2) |
Why: The relationship between the columns, not the individual numbers, is what generates the next row. We compare on ciphertext integrity, whether the receiver must decrypt before verifying, and what broke in the real world.
Worked example
Tabulate the two constructions against the properties that matter
Why: We compare on ciphertext integrity, whether the receiver must decrypt before verifying, and what broke in the real world.
| Property | Encrypt-then-MAC | MAC-then-encrypt |
|---|---|---|
| MAC computed over | the ciphertext C | the plaintext M |
| Ciphertext integrity? | yes | no |
| Decrypt attacker bytes before verify? | no — tag gate first | yes — must decrypt to find tag |
| Real-world break | none (the recommended order) | padding-oracle attack on a TLS impl |
| Two independent keys? | required (K1 ≠ K2) | required (K1 ≠ K2) |
Verify the takeaway: encrypt-then-MAC dominates on every security row
Why: §8.7: tag the ciphertext, verify before decrypting, and use two keys. Encrypt-then-MAC is the construction to reach for.
Comparison
Comparison matrix
From §8.7 The two orders, side by side: refill the Encrypt-then-MAC column from what you know. The rest of the table is as it appeared.
| Property | Encrypt-then-MAC | MAC-then-encrypt |
|---|---|---|
| MAC computed over | the ciphertext C | the plaintext M |
| Ciphertext integrity? | yes | no |
| Decrypt attacker bytes before verify? | no — tag gate first | yes — must decrypt to find tag |
| Real-world break | none (the recommended order) | padding-oracle attack on a TLS impl |
| Two independent keys? | required (K1 ≠ K2) | required (K1 ≠ K2) |
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'The MAC and the message are both inside the ciphertext, so it's all hidden — MAC-then-encrypt is perfectly safe.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: Hiding the tag does NOT give ciphertext integrity.
A student: which order avoids running decryption on attacker bytes?
Why: Hiding the tag does NOT give ciphertext integrity. The receiver must decrypt attacker-chosen bytes to even find the tag — and that decrypt-before-verify step enabled a real padding-oracle attack against TLS.
Trap
A student: 'The MAC and the message are both inside the ciphertext, so it's all hidden — MAC-then-encrypt is perfectly safe.'
Assume 'all encrypted' implies 'integrity-protected'
Why: Wrong. Hiding the tag does NOT give ciphertext integrity. The receiver must decrypt attacker-chosen bytes to even find the tag — and that decrypt-before-verify step enabled a real padding-oracle attack against TLS.
A student: which order avoids running decryption on attacker bytes?
Use encrypt-then-MAC: verify the tag on the ciphertext FIRST, decrypt only if it passes
Why: §8.7: tagging the ciphertext gives ciphertext integrity — bad input is rejected before decryption, closing the padding-oracle side channel.
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'I'll save a key — use the same K for the cipher and the MAC. One secret is simpler to manage.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: The security proofs require independent keys; a cipher and a MAC sharing a key can interact in ways that void BOTH confidentiality and integrity.
A student: how many keys does a combined scheme need?
Why: The security proofs require independent keys; a cipher and a MAC sharing a key can interact in ways that void BOTH confidentiality and integrity. It opens a whole class of attacks.
Trap
A student: 'I'll save a key — use the same K for the cipher and the MAC. One secret is simpler to manage.'
\[ K_1 = K_2 = K \;\;(\text{share one key}) \]
Reuse a single key across the cipher and the MAC
Why: Wrong. The security proofs require independent keys; a cipher and a MAC sharing a key can interact in ways that void BOTH confidentiality and integrity. It opens a whole class of attacks.
A student: how many keys does a combined scheme need?
\[ K_1 \neq K_2 \;\;(\text{derive two independent keys}) \]
Use two independent keys — one for Enc, one for MAC (e.g. derived from a master key via a KDF)
Why: §8.7: independence is what the proofs assume. Different keys for encryption and authentication is a hard rule, not a suggestion.
Section
Part 3 · §8.8 authenticated encryption
Concept
Rather than hand-assembling Enc + MAC, modern systems use a single primitive — authenticated encryption — that provides confidentiality AND integrity/authenticity together, in one vetted block-cipher mode.
AEAD (Authenticated Encryption with Associated Data) — A scheme that encrypts a payload (confidentiality) and authenticates it (integrity), AND additionally authenticates extra 'associated data' that is sent in the clear but must not be tamperable.
Intuition
You CAN build authenticated encryption yourself with encrypt-then-MAC — but every hand-assembled scheme is a chance to pick the wrong order, share a key, or mishandle the tag.
AEAD packages the safe construction once, reviewed by experts, behind one call: give it (key, nonce, payload, associated data) and it returns ciphertext + tag. Fewer knobs means fewer ways to cut yourself.
Ask yourself: which is more likely to be secure — a primitive vetted by the whole field, or a one-off you composed at 2am? (That's why the rule is 'use a vetted AEAD, never roll your own.')
Concept
Associated data (AD) — Extra data sent UNENCRYPTED alongside the ciphertext, but still covered by the integrity tag — so it's readable in transit yet cannot be altered without detection.
Classic example: a plaintext routing header — 'From Alice to Bob' — that the network must read to deliver the packet, but which an attacker must not be able to forge or rewrite.
So AEAD authenticates (encrypted payload + associated data) while only ENCRYPTING the payload. The AD travels in the clear and stays integrity-protected.
Matching
Match the pairs
Match each term to the definition this lesson gave it — not the one you would guess from the word.
Why: These are the working definitions of Encrypt-then-MAC, MAC-then-encrypt, Associated data (AD) as L24 · Authenticated Encryption & AEAD uses them. Pairing them correctly is the test of whether you could state each one with the slide switched off.
Intuition
Think of a sealed envelope inside a shipping box. The address label on the outside has to be readable so the courier can deliver it — you can't encrypt the address, or nobody could route the package.
But you still don't want a stranger swapping the label to redirect your package. AD is the address label: visible by necessity, tamper-evident by design.
Ask yourself: should the routing header be encrypted? (No — routers must read it. It must be authenticated, though, so it can't be silently rewritten.)
Step zero
Discussion prompt
§8.8 A packet: what's encrypted vs only authenticated — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.
Hint: It starts with: Build a packet with a plaintext header and a secret body
Answer:
Worked example
Build a packet with a plaintext header and a secret body
Why: The header 'From Alice to Bob' is associated data the network reads; the body is the private message only Bob should see.
Feed both to AEAD: the body becomes ciphertext, the header stays plaintext, one tag covers both
Why: AEAD encrypts the payload and authenticates payload + AD together, producing ciphertext + a single authentication tag.
| Field | Role | Encrypted? | Authenticated? |
|---|---|---|---|
| 'From Alice to Bob' header | associated data | no | yes |
| message body | payload | yes | yes |
| authentication tag | integrity check | n/a | covers header + body |
Verify: the header is readable in transit, but any tamper to header OR body fails the tag
Why: §8.8: AD gives you readable-yet-tamper-proof metadata; the body gets both secrecy and integrity. One primitive, two protections, plus authenticated headers.
Comparison
Comparison matrix
From §8.8 A packet: what's encrypted vs only authenticated: refill the Encrypted? column from what you know. The rest of the table is as it appeared.
| Field | Role | Encrypted? | Authenticated? |
|---|---|---|---|
| 'From Alice to Bob' header | associated data | no | yes |
| message body | payload | yes | yes |
| authentication tag | integrity check | n/a | covers header + body |
Step zero
Discussion prompt
§8.8 Forging the header is caught by the tag — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.
Hint: It starts with: Mallory intercepts a packet: AD header 'From Alice to Bob' +…
Answer:
Worked example
Mallory intercepts a packet: AD header 'From Alice to Bob' + encrypted body + tag
Why: The header is readable because it is associated data — sent in the clear so the network can route it.
Mallory rewrites the header to 'From Alice to Mallory' but leaves the tag unchanged
Why: She can edit the plaintext header freely — but the original tag was computed over the OLD header plus the body.
Bob recomputes the AEAD tag over (new header + body) and compares to the received tag
Why: The tag authenticates payload + AD together, so changing the AD changes the value Bob computes.
\[ \text{tag}(\text{header}' \,\Vert\, \text{body}) \neq \text{tag}(\text{header} \,\Vert\, \text{body}) \]
Verify: the tags differ, so Bob REJECTS the forged packet
Why: §8.8: AD is readable but tamper-evident — Mallory could read and rewrite the header, but she cannot make a valid tag without the key.
Blank canvas
Draw it
Draw what §8.8 Forging the header is caught by the tag just did — the shape of it, not the line-by-line working. One picture, labels only where you need them. Then check it against the steps: anything you could not draw is a step you followed rather than understood.
Concept
AEAD is the right default — but it is unforgiving. Because confidentiality and integrity flow from the SAME mechanism, a single misuse can lose both at once.
The most important misuse is reusing a nonce, which we'll see destroys an AEAD scheme completely. AEAD makes the easy path safe, but the misuse path is a cliff, not a slope.
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'AEAD authenticates the associated data, so the AD is encrypted and hidden too.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: Associated data is sent in the CLEAR — only the payload is encrypted.
A student: what protection does the AD field actually get?
Why: Associated data is sent in the CLEAR — only the payload is encrypted. AD is authenticated (tamper-evident) but fully readable. Putting a secret in the AD field leaks it.
Trap
A student: 'AEAD authenticates the associated data, so the AD is encrypted and hidden too.'
Assume 'authenticated' implies 'encrypted'
Why: Wrong. Associated data is sent in the CLEAR — only the payload is encrypted. AD is authenticated (tamper-evident) but fully readable. Putting a secret in the AD field leaks it.
A student: what protection does the AD field actually get?
Treat AD as plaintext-but-tamper-proof; put anything secret in the encrypted payload
Why: §8.8: AD = authenticated, NOT encrypted. It exists precisely for data that must be readable (headers, nonces, routing) yet unforgeable.
Section
Part 4 · §8.8 AES-GCM
Concept
AES-GCM (Galois/Counter Mode) — The most widely used AEAD. At a high level it is a stream cipher operating like AES-CTR — XORing a keystream with the message — with a built-in MAC (GHASH) that is computed as a function of the CTR encryption.
So GCM is essentially AES-CTR for confidentiality + a polynomial MAC for integrity, fused into one mode that also authenticates associated data. One pass, both guarantees.
Intuition
Because the encryption part IS essentially CTR mode, GCM inherits CTR's strengths AND its single fatal weakness. CTR is IND-CPA — but only if every message uses a fresh nonce/IV.
Recall L21: CTR generates a keystream from (key, IV) and XORs it with the message — that's a one-time pad with a pseudorandom pad. Reuse the IV and you reuse the pad.
Ask yourself: from L21, what happens when CTR reuses an IV across two messages? (Same keystream ⇒ C ⊕ C′ = M ⊕ M′ — the two-time pad returns.)
Explain it
Discussion prompt
Explain §8.8 Its security mirrors CTR's security to a student a year behind you. No notation, no jargon they have not met — and it still has to be true.
Hint: If your explanation needs a symbol they have never seen, you are describing the notation rather than the idea.
Answer:
Because the encryption part IS essentially CTR mode, GCM inherits CTR's strengths AND its single fatal weakness. CTR is IND-CPA — but only if every message uses a fresh nonce/IV.
Ranking
Put in order
Put the moves of §8.8 Why GCM nonce reuse loses BOTH properties into the order they have to happen.
Why: These are the moves of the worked example in the order it makes them, and each one is set up by the one before it. GCM derives its keystream from (K, N) exactly like CTR; a repeated nonce means the SAME keystream encrypts both messages.
Worked example
Reuse one nonce N with key K on two messages M and M′
Why: GCM derives its keystream from (K, N) exactly like CTR; a repeated nonce means the SAME keystream encrypts both messages.
Confidentiality falls: identical keystream gives the two-time pad
Why: C = M ⊕ keystream and C′ = M′ ⊕ keystream, so C ⊕ C′ = M ⊕ M′ — exactly the L21 / L19 key-reuse leak, no key needed.
\[ C \oplus C' = M \oplus M' \quad(\text{two-time pad, again}) \]
Integrity ALSO falls: GCM's MAC depends on the CTR encryption, so the repeated nonce exposes the MAC's secret values
Why: Because the built-in GHASH authentication is a function of the same nonce-derived encryption, two messages under one nonce let an attacker solve for the MAC's internal key and FORGE tags.
Verify: nonce reuse is catastrophic — it destroys confidentiality AND integrity at once
Why: §8.8: this is the AEAD fragility made concrete. A single repeated nonce loses both guarantees — far worse than CTR alone, which only lost confidentiality.
Notation
Annotate
From §8.8 Why GCM nonce reuse loses BOTH properties — read this one piece at a time. What is each part doing?
On: \( C \oplus C' = M \oplus M' \quad(\text{two-time pad, again}) \)
Intuition
In L21, reusing a CTR IV cost you confidentiality — the two-time pad — but integrity wasn't on the table, because plain CTR never promised it.
GCM bundles integrity in, and ties its MAC to the same nonce-derived encryption. So the one mistake that breaks confidentiality ALSO unravels the MAC's secret — you lose the property you added GCM to get.
Ask yourself: with GCM, is a repeated nonce a 'lose one property' bug or a 'lose everything' bug? (Everything — which is why unique nonces are non-negotiable.)
Analogy
Discussion prompt
Explain §8.8 Why nonce reuse is WORSE than plain CTR reuse by analogy to something with no Computer Security in it at all — a queue, a recipe, a map, a bank balance, whatever fits. Then say where your analogy breaks.
Hint: An analogy that never breaks is not an analogy, it is the same idea wearing a hat. Find the seam — that is the part that is actually new.
Answer:
In L21, reusing a CTR IV cost you confidentiality — the two-time pad — but integrity wasn't on the table, because plain CTR never promised it.
Concept
Other AEAD modes exist — CCM, CWC, OCB — but they are out of scope here; AES-GCM is the one to know.
⊕ Beyond this textbook: ChaCha20-Poly1305 is a software-friendly AEAD (no AES hardware needed) used in TLS 1.3 and WireGuard, and AES-GCM-SIV is a nonce-misuse-resistant variant that degrades gracefully if a nonce repeats. Flagged as supplemental — not §8.8 material.
Counterexample
Discussion prompt
Other AEAD modes exist — CCM, CWC, OCB — but they are out of scope here; AES-GCM is the one to know.
That is stated as though it always holds. Do one of two things: produce a case where it fails, or say precisely what rules such a case out. "It just does" is not on the menu.
Hint: Hunt at the extremes first — zero, one, negative, empty, equal. If every extreme survives, the reason they survive is the proof.
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'GCM has a built-in MAC, so even if I repeat a nonce the integrity protects me — reuse is no big deal.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: Backwards — and catastrophically so.
A student: what is the one rule I must never break with AES-GCM?
Why: Backwards — and catastrophically so. Because the MAC is derived from the CTR encryption, reuse loses BOTH confidentiality (C ⊕ C′ = M ⊕ M′) AND integrity (the attacker can forge tags). The MAC makes reuse worse, not safer.
Trap
A student: 'GCM has a built-in MAC, so even if I repeat a nonce the integrity protects me — reuse is no big deal.'
Assume the built-in MAC makes nonce reuse survivable
Why: Backwards — and catastrophically so. Because the MAC is derived from the CTR encryption, reuse loses BOTH confidentiality (C ⊕ C′ = M ⊕ M′) AND integrity (the attacker can forge tags). The MAC makes reuse worse, not safer.
A student: what is the one rule I must never break with AES-GCM?
Never reuse a (key, nonce) pair — generate a fresh unique nonce for every message
Why: §8.8: GCM's security mirrors CTR's, so a repeated nonce is the two-time pad PLUS tag forgery. If you cannot guarantee unique nonces, use a nonce-misuse-resistant mode (AES-GCM-SIV).
Two truths and a lie
Sort into buckets
Some of these hold up and some are the exact mistakes this lesson is built to prevent. Sort them.
Section
Part 5 · §8.6–8.8 choosing a primitive
Concept
Pin down what you actually need, then pick the matching primitive. The wrong tool for the goal is how systems get broken.
| Your goal | Use | Notes |
|---|---|---|
| Confidentiality only | AES-CBC or AES-CTR | IND-CPA; gives NO integrity |
| Integrity / authenticity only | HMAC or AES-based MAC (e.g. CMAC) | unforgeable; gives NO secrecy |
| Both, from parts | encrypt-then-MAC | tag the ciphertext; two independent keys |
| Both, one primitive | AEAD — AES-GCM | + associated data; NEVER reuse a nonce |
Comparison
Comparison matrix
From §8.6–8.8 Goal → primitive: the master table: refill the Use column from what you know. The rest of the table is as it appeared.
| Your goal | Use | Notes |
|---|---|---|
| Confidentiality only | AES-CBC or AES-CTR | IND-CPA; gives NO integrity |
| Integrity / authenticity only | HMAC or AES-based MAC (e.g. CMAC) | unforgeable; gives NO secrecy |
| Both, from parts | encrypt-then-MAC | tag the ciphertext; two independent keys |
| Both, one primitive | AEAD — AES-GCM | + associated data; NEVER reuse a nonce |
Concept
Constraint
Discussion prompt
Run The authenticated-encryption playbook with this step confiscated:
Two keys always: K1 ≠ K2 for encryption and MAC — independence is what the proofs require.
Is it still possible? If it is, say what takes its place and what it costs you. If it is not, say exactly what that step was providing that nothing else does.
Hint: A step you can drop for free was never load-bearing. If you cannot drop it, name the thing that goes wrong the moment it is gone.
Answer:
Pattern
Edge cases
Discussion prompt
The authenticated-encryption playbook works on the cases you have just seen. Push it to the edge: what is the most degenerate input it still handles — empty, zero, one item, everything equal — and what is the first case where it stops being true? Name the case, not just "it breaks".
Hint: Try the smallest legal input, then the largest, then the one where two things collide. Methods are specified at their edges; the middle takes care of itself.
Answer:
Elimination
Eliminate the wrong options
Which design choice is the secure one, and why?
3 of these 4 are wrong. Strike them one at a time, and say what rules each one out before you strike the next. The survivor is the answer.
Survives elimination: A
Why: §8.7: encrypt-then-MAC computes the MAC over the ciphertext C, so the receiver checks the tag FIRST and only decrypts if it passes. That gives ciphertext integrity and never runs decryption on attacker-chosen bytes — exactly what blocks the padding-oracle class of attacks. The encryption and MAC keys must be independent (K1 ≠ K2).
Check
You're designing a protocol that needs both confidentiality and integrity, and you must combine an IND-CPA cipher with a MAC by hand. Think it through before clicking.
Check your understanding
Which design choice is the secure one, and why?
Answer: A
Why: §8.7: encrypt-then-MAC computes the MAC over the ciphertext C, so the receiver checks the tag FIRST and only decrypts if it passes. That gives ciphertext integrity and never runs decryption on attacker-chosen bytes — exactly what blocks the padding-oracle class of attacks. The encryption and MAC keys must be independent (K1 ≠ K2).
Concept
Concept
Concept
Connect it up
Draw it
One page, no notation unless you need it: draw how these connect — A MAC Hides Nothing · Combining Encryption and a MAC · AEAD & Associated Data · The Concrete AEAD: AES-GCM · The Decision Recap. Put an arrow wherever one of them is what makes another possible, and label the arrow with why.
Recap
You can now explain why a MAC gives no confidentiality (and build F′ to prove it), compare encrypt-then-MAC with MAC-then-encrypt and its padding-oracle break, define AEAD and associated data, and state why AES-GCM nonce reuse is catastrophic — the L21 two-time pad plus tag forgery.
| Idea | § | The one-line version |
|---|---|---|
| MAC ≠ secrecy | 8.6 | F′(K,M)=F(K,M)‖M is a secure MAC that leaks all of M |
| Encrypt-then-MAC | 8.7 | C=Enc_{K1}(M), T=MAC_{K2}(C); verify before decrypt |
| MAC-then-encrypt | 8.7 | no ciphertext integrity ⇒ TLS padding-oracle break |
| Two keys | 8.7 | K1 ≠ K2 for encryption and MAC — always |
| AEAD + AD | 8.8 | both properties in one; AD authenticated, not encrypted |
| AES-GCM | 8.8 | CTR + built-in MAC; nonce reuse loses BOTH (catastrophic) |
| Rules | 8.6–8.8 | never roll your own; use AEAD; never reuse a nonce |
Want this taught 1-on-1? Alexander tutors Computer Security — $55/session, free consultation.