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.
Subject: Computer Security · 83 slides · applied lesson
Open the interactive version of this deck · Homework for this lesson
Title
CS 161 · Lesson 23 of 45
what a MAC is · EUF-CMA unforgeability · AES-EMAC · HMAC and the ipad/opad transform
Objectives
Warm-up
Discussion prompt
Before we open L23 · Message Authentication Codes: EUF-CMA, AES-EMAC, HMAC: without looking back, what was the main idea of L22 · Cryptographic Hash Functions, 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 22, in 51 slides. It explains what a cryptographic hash is and why it is avalanche-prone, deterministic, and unkeyed, in section 7.1, then gives the three security properties in section 7.2: preimage resistance, second-preimage resistance, and collision resistance. It covers using hashes for integrity and the trusted-channel limit, also in section 7.2, then real algorithms, including SHA-2's length-extension flaw and the birthday bound, in section 7.3, and closes with the lowest-hash verification scheme in section 7.4. It is anchored to textbook sections 7.1 to 7.4.
Concept
Encryption from earlier lessons hides what a message says. It does not stop an attacker from changing it or forging a new one. A MAC is the tool that fixes that.
Matching
Match the pairs
From Three questions this lesson answers — match each one to what it actually does. The descriptions have been shuffled.
Why: What is the tool?, When is it secure?, How is it built? 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.1–8.2 integrity & authenticity
Concept
Alice sends Bob the message 'Transfer $100 to Mallory.' Even if Eve cannot read an encrypted version, two attacks remain: Eve could tamper with it (change $100 to $9000) or spoof it (forge a brand-new message that looks like it came from Alice).
Bob wants a way to check, before acting, that the message arrived unmodified and that it really came from Alice. Encryption alone gives neither guarantee. A MAC does.
Counterexample
Discussion prompt
Bob wants a way to check, before acting, that the message arrived unmodified and that it really came from Alice. Encryption alone gives neither guarantee. A MAC does.
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
Integrity — The message Bob receives is exactly the message Alice sent — no bit was modified, added, or dropped in transit.
Authenticity — The message really came from someone holding the shared secret key — not from an impostor who spoofed Alice's identity.
A MAC delivers both at once: tampering and spoofing both produce a tag Bob will reject.
Definition probe
Sort into buckets
Every line below is part of the definition of Integrity or of Authenticity — one or the other, never both. Put each where it belongs.
Concept
Message Authentication Code (MAC) — A function F that takes a fixed-length secret key K and an arbitrary-length message M, and outputs a fixed-length tag T = F(K, M). Typically K is 128 bits and T is 128 bits.
\[ T = F(K, M) \]
Think of it as a checksum that only someone with the key can compute or check. Without K, an attacker cannot produce a valid tag.
Analogy
Discussion prompt
Explain §8.2 A MAC: a keyed checksum 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:
Think of it as a checksum that only someone with the key can compute or check. Without K, an attacker cannot produce a valid tag.
Concept
Unlike encryption (which we WANT to be randomized for IND-CPA), a MAC is deterministic: the same key and message always yield the same tag.
This is required for correctness — Bob recomputes F(K, M) himself and compares. If the function returned a different tag each time, Bob's recomputed tag would never match Alice's, and he could never accept a legitimate message.
Explain it
Discussion prompt
Explain §8.2 A MAC must be deterministic 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:
Unlike encryption (which we WANT to be randomized for IND-CPA), a MAC is deterministic: the same key and message always yield the same tag.
Intuition
A MAC is like a tamper-evident seal that only Alice and Bob know how to make. Alice stamps the seal onto the message; Bob, who knows the same secret recipe, re-stamps the message he received and checks the two seals match.
If Eve changes even one bit, Bob's re-stamp comes out different, the seals disagree, and Bob throws the message away. Eve can't fake a fresh seal because she doesn't know the recipe (the key).
Ask yourself: what does Bob actually compare? (His own freshly-computed F(K, M) against the tag T that arrived alongside M.)
Ranking
Put in order
Put the moves of §8.2 Walk the send-and-verify protocol 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. She holds the shared key K; the tag is a fixed-length fingerprint of M under that key.
Worked example
Alice computes the tag over her message: T = F(K, M)
Why: She holds the shared key K; the tag is a fixed-length fingerprint of M under that key.
Alice sends the pair (M, T) — the message in the clear plus its tag
Why: A MAC does not encrypt; M travels readable. The tag T rides alongside it.
Bob receives (M′, T′) — possibly altered by Eve in transit
Why: Bob cannot assume the pair is untouched; that is exactly what he is about to test.
Bob recomputes the tag on what he got: F(K, M′)
Why: He has the same key K, so he can compute the legitimate tag for the message he actually received.
Bob accepts iff F(K, M′) equals T′; otherwise he rejects
Why: A match means M′ = M and T′ is genuine (overwhelmingly likely); any tampering or spoofing makes the recomputed tag differ.
Verify: if Eve changed M, Bob's recomputed tag won't match the old T
Why: §8.2: a secure MAC makes it infeasible for Eve to produce a matching tag for any message she altered or invented, so Bob's check catches her.
Blank canvas
Draw it
Draw what §8.2 Walk the send-and-verify protocol 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
The 'sender' and 'receiver' can be the same person at different times. MAC each file on a USB stick with your own key; later, recompute the tags to confirm nothing was altered while the drive was out of your control.
It's 'communicating to your future self.' The integrity/authenticity guarantee is the same — only the channel is time instead of a network wire.
Intuition
A CRC or ordinary checksum catches accidental noise on a wire, but it has NO secret. Anyone — including Eve — can recompute it.
So if Eve changes the message, she simply recomputes the checksum to match and Bob is fooled. The key is the whole point: without it, Eve can't forge a tag; with a plain checksum, there's nothing to stop her.
Ask yourself: what does the secret key add that a CRC lacks? (Only a key-holder can produce a valid tag, so a tag proves a key-holder made it — authenticity, not just error-detection.)
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'Since the MAC uses a secret key, attaching a tag must keep the message secret too.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: A MAC gives integrity and authenticity, NOT confidentiality.
A student: what exactly does a MAC protect?
Why: A MAC gives integrity and authenticity, NOT confidentiality. The pair (M, T) is sent with M fully in the clear — Eve reads M directly. Hiding M needs encryption, a separate tool.
Trap
A student: 'Since the MAC uses a secret key, attaching a tag must keep the message secret too.'
\[ \text{send } (M, T) \;\Rightarrow\; M \text{ is hidden?} \]
Assume the MAC provides confidentiality
Why: Wrong. A MAC gives integrity and authenticity, NOT confidentiality. The pair (M, T) is sent with M fully in the clear — Eve reads M directly. Hiding M needs encryption, a separate tool.
A student: what exactly does a MAC protect?
\[ \text{MAC} \to \text{integrity} + \text{authenticity}, \;\text{NOT secrecy} \]
Pin the guarantee to integrity + authenticity only
Why: §8.2: a MAC proves M was not tampered with and came from a key-holder. The message itself is public. For secrecy, combine a MAC with encryption (authenticated encryption, next lesson).
Notation
Annotate
From Trap: 'a MAC hides the message' — read this one piece at a time. What is each part doing?
On: \( \text{send } (M, T) \;\Rightarrow\; M \text{ is hidden?} \)
Section
Part 2 · §8.3 EUF-CMA
Concept
A MAC is secure if an attacker cannot forge a valid tag on a message of their choosing — even after watching legitimate traffic.
Existential unforgeability (EUF-CMA) — Even after seeing many (M_i, T_i) pairs — including ones the attacker chose — the attacker cannot produce a valid tag on ANY new message they haven't already gotten a tag for.
Concept
An attacker can always just guess a tag. For a 128-bit tag, a random guess validates with probability about 1/2^128.
\[ \Pr[\text{random tag valid}] \approx \tfrac{1}{2^{128}} \]
That number is negligible — astronomically smaller than any real-world chance. A secure MAC ensures this is the BEST the attacker can do.
Concept
We make 'unforgeable' precise with a game between an adversary Georgia and a referee Reginald.
Intuition
Generation queries model Eve watching Alice send messages — she collects real (M, T) pairs off the wire, even ones she tricked Alice into sending. That's the 'chosen-message' power.
Verification queries model Eve submitting forged messages to Bob and seeing whether he accepts. Georgia winning means she fooled Bob with a message Alice never tagged — exactly a real forgery.
Ask yourself: why must the winning message be NEW? (Re-sending a genuine (M, T) pair isn't a forgery — Alice already authorized it. The threat is a message Alice never approved.)
Concept
If no efficient strategy lets Georgia win with more than negligible probability, the MAC is EUF-CMA secure.
This is the strongest model: secure even against chosen-message attacks. Eve can collect as many tags as she likes on whatever messages she likes and still cannot tag a new one.
Step zero
Discussion prompt
§8.3 Play two rounds of the forgery game — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.
Hint: It starts with: Reginald draws a secret key K; Georgia knows F but not K
Answer:
Worked example
Reginald draws a secret key K; Georgia knows F but not K
Why: Kerckhoff's principle: the algorithm is public, only the key is secret.
Round 1 — Georgia generation-queries M_1 = 'pay $5' and gets T_1 = F(K, M_1)
Why: She now holds one genuine (M_1, T_1) pair, just like sniffing one message off the wire.
Round 2 — Georgia generation-queries M_2 = 'pay $7' and gets T_2
Why: A second genuine pair. She can repeat this for as many chosen messages as she wants.
Georgia now verification-queries the NEW message ('pay $9000', T) for some tag T she cooked up
Why: This message never appeared in a generation query, so a 'Yes' here would be a forgery — a win.
Against a secure MAC, Reginald answers 'No' (except with prob ≈ 1/2^128)
Why: The genuine pairs T_1, T_2 give Georgia no leverage to compute the tag for a different message.
Verify: Georgia cannot do better than guessing, so the MAC is unforgeable
Why: §8.3: if every strategy leaves her at the ≈ 1/2^128 guessing bound, no efficient adversary forges — the definition of EUF-CMA security.
Blank canvas
Draw it
Draw what §8.3 Play two rounds of the forgery game 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.
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'Once Eve has a bunch of valid (M, T) pairs, she can combine them to make a tag for a new message.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: Wrong — that is precisely what a secure MAC prevents.
A student: what do known (M, T) pairs actually buy an attacker?
Why: Wrong — that is precisely what a secure MAC prevents. The EUF-CMA game GIVES Georgia all the pairs she wants (generation queries) and she still cannot tag a message she didn't query.
Trap
A student: 'Once Eve has a bunch of valid (M, T) pairs, she can combine them to make a tag for a new message.'
Assume known pairs leak the ability to tag new messages
Why: Wrong — that is precisely what a secure MAC prevents. The EUF-CMA game GIVES Georgia all the pairs she wants (generation queries) and she still cannot tag a message she didn't query.
A student: what do known (M, T) pairs actually buy an attacker?
Nothing useful against a secure MAC — no new tag follows from old pairs
Why: §8.3: EUF-CMA security means even a chosen-message attacker who collects unlimited valid pairs cannot forge a tag on a new message. (A BROKEN MAC like Hash(K‖M) is exactly where this fails.)
Ranking
Put in order
Put the moves of §8.3 Win the game against a BROKEN MAC 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 NOT EUF-CMA secure; we'll let Georgia win to see what a forgeable MAC looks like.
Worked example
Suppose a careless MAC is defined as F(K, M) = K ⊕ M (one fixed-length block)
Why: This is NOT EUF-CMA secure; we'll let Georgia win to see what a forgeable MAC looks like.
Georgia generation-queries M_1 and gets T_1 = K ⊕ M_1
Why: One genuine pair off the wire — exactly the chosen-message power the game grants.
Georgia recovers the key: K = T_1 ⊕ M_1
Why: Since T_1 = K ⊕ M_1, XOR-ing the known M_1 back cancels it and exposes K — the construction leaks its own key.
\[ K = T_1 \oplus M_1 \]
Forge a tag on a NEW message M* ≠ M_1: T* = K ⊕ M*
Why: With K in hand Georgia tags anything; (M, T) verifies though M* was never generation-queried — a forgery.
Verify: Reginald says 'valid' on a new message, so Georgia wins
Why: §8.3: this MAC fails EUF-CMA outright. A SECURE MAC (AES-EMAC, HMAC) gives no such leverage — the contrast is the point of the next two parts.
Translation
\( K = T_1 \oplus M_1 \)
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.
Section
Part 3 · §8.4 a CBC-MAC construction
Concept
We have AES, a secure block cipher on 128-bit blocks. But our message is arbitrary length and a tag must be fixed length. How do we squeeze a long message down to one 128-bit tag using AES?
The answer is AES-EMAC, a CBC-MAC construction: chain the message blocks through AES, then seal the result with a second key.
Concept
AES-EMAC — A MAC keyed by K = (K1, K2), two independent 128-bit AES keys. The message M is split into 128-bit blocks P_1 … P_n. K1 chains the blocks; K2 encrypts the final chained value into the tag.
\[ K = (K_1, K_2), \qquad M = P_1 \,\|\, P_2 \,\|\, \cdots \,\|\, P_n \]
Each P_i is one 128-bit block; ‖ denotes concatenation of the blocks that make up M.
Concept
Start the chain at zero, then fold in each block by XOR-then-encrypt under K1:
\[ S_0 = 0 \]
\[ S_i = \mathrm{AES}_{K_1}(S_{i-1} \oplus P_i), \quad i = 1, \ldots, n \]
Each block is XOR-ed with the running state, then encrypted — so the state after block i depends on every block up to i.
Sorting
Sort into buckets
These are the pieces of L23 · Message Authentication Codes: EUF-CMA, AES-EMAC, HMAC, out of order. Put each one back under the part of the lesson it belongs to.
Concept
After folding in all n blocks, the tag is the final state encrypted once more, under the second key K2:
\[ T = \mathrm{AES}_{K_2}(S_n) \]
That extra encryption under a DIFFERENT key is what fixes plain CBC-MAC's weakness on variable-length messages (the length-extension / splicing attack). AES-EMAC is provably secure if AES is a secure block cipher.
Intuition
Plain CBC-MAC (no final re-encryption) is only safe when every message is the same fixed length. With variable lengths, an attacker can splice tags of short messages together to forge a tag for a longer one.
Sealing S_n under a separate key K2 hides the raw chaining value, so the attacker can't use one message's tag as an intermediate state for another. The two keys make the splice impossible.
Ask yourself: what would go wrong if we sealed with K1 instead of a new K2? (The tag would be a normal chaining value AES_{K1}(...), which the attacker could feed back into the chain to extend the message — the very attack we're closing.)
Step zero
Discussion prompt
§8.4 Trace AES-EMAC over a 3-block message — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.
Hint: It starts with: Split M into three 128-bit blocks P_1, P_2, P_3 and set S_0 = 0
Answer:
Worked example
Split M into three 128-bit blocks P_1, P_2, P_3 and set S_0 = 0
Why: The chain always starts at the all-zero state; each block will be folded in one at a time.
Block 1: S_1 = AES_{K1}(S_0 ⊕ P_1) = AES_{K1}(0 ⊕ P_1)
Why: XOR P_1 into the zero state, then encrypt under K1. Since S_0 = 0, this is just AES_{K1}(P_1).
Block 2: S_2 = AES_{K1}(S_1 ⊕ P_2)
Why: XOR the previous state into P_2, encrypt under K1 — now S_2 depends on both P_1 and P_2.
Block 3: S_3 = AES_{K1}(S_2 ⊕ P_3)
Why: Fold in the last block the same way; S_3 depends on the entire message.
| step | input to AES_{K1} | state out |
|---|---|---|
| S_0 | — | 0 |
| S_1 | S_0 ⊕ P_1 = P_1 | AES_{K1}(P_1) |
| S_2 | S_1 ⊕ P_2 | AES_{K1}(S_1 ⊕ P_2) |
| S_3 | S_2 ⊕ P_3 | AES_{K1}(S_2 ⊕ P_3) |
| T | S_3 (under K2) | AES_{K2}(S_3) |
Verify: the tag is T = AES_{K2}(S_3), the final state sealed under K2
Why: §8.4: every block influenced S_3, and the K2 seal closes the variable-length hole — a provably secure MAC when AES is secure.
Comparison
Comparison matrix
From §8.4 Trace AES-EMAC over a 3-block message: refill the input to AES_{K1} column from what you know. The rest of the table is as it appeared.
| step | input to AES_{K1} | state out |
|---|---|---|
| S_0 | — | 0 |
| S_1 | S_0 ⊕ P_1 = P_1 | AES_{K1}(P_1) |
| S_2 | S_1 ⊕ P_2 | AES_{K1}(S_1 ⊕ P_2) |
| S_3 | S_2 ⊕ P_3 | AES_{K1}(S_2 ⊕ P_3) |
| T | S_3 (under K2) | AES_{K2}(S_3) |
Intuition
Why XOR the previous state into each block before encrypting? Because it makes every output depend on the ENTIRE message so far — reorder, swap, or drop a block and the final state changes completely.
If we instead encrypted each block independently and XOR-ed the results, an attacker could permute blocks freely without changing the tag. Chaining is what binds the blocks into one inseparable order.
Ask yourself: what carries information from block i forward to block i+1? (The state S_i, fed into the XOR at the next step — a chain link.)
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'Two keys is wasteful — just use K1 for the chaining AND the final encryption: T = AES_{K1}(S_n).'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: Insecure for variable-length messages.
A student: why keep K1 and K2 separate?
Why: Insecure for variable-length messages. With one key the tag is itself a valid chaining value, so an attacker can splice/extend messages and forge tags — the exact weakness EMAC's second key removes.
Trap
A student: 'Two keys is wasteful — just use K1 for the chaining AND the final encryption: T = AES_{K1}(S_n).'
\[ T \stackrel{?}{=} \mathrm{AES}_{K_1}(S_n) \]
Collapse the two keys into one
Why: Insecure for variable-length messages. With one key the tag is itself a valid chaining value, so an attacker can splice/extend messages and forge tags — the exact weakness EMAC's second key removes.
A student: why keep K1 and K2 separate?
\[ T = \mathrm{AES}_{K_2}(S_n), \quad K_2 \neq K_1 \]
Seal the chain under an INDEPENDENT key K2
Why: §8.4: the second key hides the raw chaining state so it cannot be reused to extend a message. The two-key final step is essential — it is what makes AES-EMAC provably secure on variable-length input.
Notation
Annotate
From Trap: 'use one key for chain and final block' — read this one piece at a time. What is each part doing?
On: \( T = \mathrm{AES}_{K_2}(S_n), \quad K_2 \neq K_1 \)
Section
Part 4 · §8.5 NMAC → HMAC
Concept
We already have a fast cryptographic hash H (SHA-256 from Lesson 22). Can we turn it into a MAC by mixing in a key? We can — but the obvious ways are broken, so it must be done carefully.
The right construction is HMAC, today's most widely deployed MAC. We reach it by way of a cleaner stepping-stone, NMAC.
Concept
NMAC — A nested MAC with two independent keys K1, K2, each n bits long (n = the hash output length). Hash the message under one key, then hash that result under the other.
\[ \mathrm{NMAC}(K_1, K_2, M) = H(K_1 \,\|\, H(K_2 \,\|\, M)) \]
The inner hash binds the message to K2; the outer hash binds that to K1. NMAC is provably secure if H is a cryptographic hash.
Concept
NMAC needs two independent keys, which is awkward in practice. HMAC keeps NMAC's nested structure but derives both keys from a single key K, using two fixed pads:
\[ \mathrm{HMAC}(M, K) = H\big((K' \oplus \text{opad}) \,\|\, H((K' \oplus \text{ipad}) \,\|\, M)\big) \]
K′ is K transformed to exactly n bits (next slide). XOR-ing K′ with two DIFFERENT pads produces the two 'unrelated' keys NMAC wanted.
Concept
Before padding, the single key K is normalized to exactly n bits (the hash's block/output length):
The result K′ is exactly n bits, so XOR-ing with the n-bit pads is well-defined.
Concept
ipad / opad — Two fixed constants, each one byte repeated to fill n bits. ipad = 0x36 repeated; opad = 0x5c repeated. XOR-ing K′ with each pad yields the inner key and the outer key.
\[ K_{\text{in}} = K' \oplus \text{ipad}, \qquad K_{\text{out}} = K' \oplus \text{opad} \]
Because 0x36 ≠ 0x5c, the inner and outer keys differ — that is what gives HMAC NMAC's 'two unrelated keys' from just one.
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 Integrity, Authenticity, NMAC, ipad / opad as L23 · Message Authentication Codes: EUF-CMA, AES-EMAC, HMAC uses them. Pairing them correctly is the test of whether you could state each one with the slide switched off.
Intuition
The inner hash, H((K′ ⊕ ipad) ‖ M), compresses the whole message down to a fixed-size digest, keyed so an attacker can't compute it without K.
The outer hash, keyed with a DIFFERENT pad, wraps that digest so the final tag can't be extended or spliced. Two different pads mean the inner and outer keys behave like independent secrets — exactly NMAC's requirement, achieved with one shared key.
Ask yourself: why use two different pads instead of the same one twice? (Same pad would make the inner and outer keys identical, collapsing the two-key nesting NMAC relies on for its proof.)
Concept
HMAC's output is n bits — the same width as the underlying hash. It is provably secure: breaking HMAC implies breaking the hash itself.
It's also efficient: the inner hash covers the message plus n bits, and the outer hash covers only 2n bits (a short fixed amount). This is why HMAC-SHA256 is everywhere — TLS, IPsec, JWTs, API signatures.
Explain it
Discussion prompt
Explain §8.5 HMAC is provable, efficient, and standard 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:
HMAC's output is n bits — the same width as the underlying hash. It is provably secure: breaking HMAC implies breaking the hash itself.
Ranking
Put in order
Put the moves of §8.5 Trace HMAC inner-then-outer 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. The pads are n bits, so the key must be n bits before XOR-ing.
Worked example
Transform K to K′: pad short K with zeros (or hash long K) to n bits
Why: The pads are n bits, so the key must be n bits before XOR-ing. Here say K is short, so K′ = K ‖ 0…0.
Form the inner key: K_in = K′ ⊕ ipad = K′ ⊕ (0x36 repeated)
Why: XOR K′ with the ipad constant to get the first of the two 'unrelated' keys.
Inner hash: h = H(K_in ‖ M)
Why: Prepend the inner key to the message and hash; h is an n-bit digest binding M to K.
Form the outer key: K_out = K′ ⊕ opad = K′ ⊕ (0x5c repeated)
Why: XOR the SAME K′ with the other pad opad; since 0x36 ≠ 0x5c this key differs from K_in.
| stage | computation | width |
|---|---|---|
| K → K′ | pad/hash K to n bits | n bits |
| inner key | K′ ⊕ ipad (0x36…) | n bits |
| inner hash h | H(K_in ‖ M) | n bits |
| outer key | K′ ⊕ opad (0x5c…) | n bits |
| tag T | H(K_out ‖ h) | n bits |
Verify: T = H(K_out ‖ h) = H((K′ ⊕ opad) ‖ H((K′ ⊕ ipad) ‖ M))
Why: §8.5: this is exactly the HMAC definition — NMAC's nesting with both keys derived from one K via ipad/opad. Output is n bits, provably secure if H is.
Comparison
Comparison matrix
From §8.5 Trace HMAC inner-then-outer: refill the width column from what you know. The rest of the table is as it appeared.
| stage | computation | width |
|---|---|---|
| K → K′ | pad/hash K to n bits | n bits |
| inner key | K′ ⊕ ipad (0x36…) | n bits |
| inner hash h | H(K_in ‖ M) | n bits |
| outer key | K′ ⊕ opad (0x5c…) | n bits |
| tag T | H(K_out ‖ h) | n bits |
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'Just prepend the key and hash: T = H(K ‖ M). The key is secret, so the tag is unforgeable.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: Insecure for SHA-2: the Merkle–Damgård length-extension property (Lesson 22) lets an attacker, given H(K ‖ M), compute H(K ‖ M ‖ pad ‖ M) for an extension M WITHOUT knowing K — a forgery on a new message.
A student: how do we use a hash safely as a MAC?
Why: Insecure for SHA-2: the Merkle–Damgård length-extension property (Lesson 22) lets an attacker, given H(K ‖ M), compute H(K ‖ M ‖ pad ‖ M) for an extension M WITHOUT knowing K — a forgery on a new message.
Trap
A student: 'Just prepend the key and hash: T = H(K ‖ M). The key is secret, so the tag is unforgeable.'
\[ T \stackrel{?}{=} H(K \,\|\, M) \]
Use a single prefixed hash as the MAC
Why: Insecure for SHA-2: the Merkle–Damgård length-extension property (Lesson 22) lets an attacker, given H(K ‖ M), compute H(K ‖ M ‖ pad ‖ M) for an extension M WITHOUT knowing K — a forgery on a new message.
A student: how do we use a hash safely as a MAC?
\[ T = H((K' \oplus \text{opad}) \,\|\, H((K' \oplus \text{ipad}) \,\|\, M)) \]
Use HMAC's nested two-pass structure
Why: §8.5: the outer hash wraps the inner digest, so length-extension on the inner hash buys nothing — the attacker would still have to forge the outer hash. The nesting is precisely why HMAC is safe where Hash(K‖M) is not.
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.5 failed constructions
Concept
Before trusting HMAC, see why the obvious shortcuts are all broken:
Analogy
Discussion prompt
Explain §8.5 The three naive MACs and why each fails 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:
Before trusting HMAC, see why the obvious shortcuts are all broken:
Concept
HMAC's nested H(K_out ‖ H(K_in ‖ M)) sidesteps every failure: it has a key (unlike H(M)); the outer hash blocks length-extension on the inner one (unlike H(K‖M)); and a message collision is wrapped by a keyed outer hash (unlike H(M‖K)).
That is the payoff of the careful design: one construction, provably secure, immune to the attacks that sink each naive attempt.
Intuition
Both AES-EMAC and HMAC are secure MACs — they just build on different primitives. If your system already has a hardware AES engine, EMAC reuses it; if you already have a fast hash, HMAC reuses that.
In practice HMAC won the deployment race: it's in TLS, IPsec, JWTs, and AWS request signing, because cryptographic hashes were already everywhere. Both share the same lesson — a secure MAC is a careful construction, never an ad-hoc 'key plus checksum.'
Ask yourself: what do EMAC's two-key seal and HMAC's two-pad nesting have in common? (Both use a SECOND independent keying step to close a structural attack — splicing for EMAC, length-extension for HMAC.)
Counterexample
Discussion prompt
Both AES-EMAC and HMAC are secure MACs — they just build on different primitives. If your system already has a hardware AES engine, EMAC reuses it; if you already have a fast hash, HMAC reuses that.
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.
Constraint
Discussion prompt
Run The MAC playbook with this step confiscated:
AES-EMAC (§8.4): S_0 = 0, S_i = AES_{K1}(S_{i-1} ⊕ P_i), then T = AES_{K2}(S_n). The SECOND key K2 fixes variable-length CBC-MAC.
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 MAC 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
Why is T = H(K ‖ M) (with SHA-256) NOT a secure MAC, and why is HMAC safe instead?
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.5: SHA-256 is Merkle–Damgård, so given H(K ‖ M) an attacker can compute H(K ‖ M ‖ pad ‖ M) for a chosen extension M WITHOUT knowing K — an existential forgery on a new message, breaking EUF-CMA. HMAC nests the keyed hash inside a second keyed hash, H(K_out ‖ H(K_in ‖ M)), so length-extension on the inner hash produces a value the attacker still cannot wrap in the outer keyed hash. That nesting is exactly why HMAC is safe where Hash(K‖M) is not.
Check
A developer defines their MAC as T = H(K ‖ M), where H is SHA-256 and K is a secret key. They argue: 'The key is secret, so no one can forge a tag.' Decide whether this is secure before clicking.
Check your understanding
Why is T = H(K ‖ M) (with SHA-256) NOT a secure MAC, and why is HMAC safe instead?
Answer: A
Why: §8.5: SHA-256 is Merkle–Damgård, so given H(K ‖ M) an attacker can compute H(K ‖ M ‖ pad ‖ M) for a chosen extension M WITHOUT knowing K — an existential forgery on a new message, breaking EUF-CMA. HMAC nests the keyed hash inside a second keyed hash, H(K_out ‖ H(K_in ‖ M)), so length-extension on the inner hash produces a value the attacker still cannot wrap in the outer keyed hash. That nesting is exactly why HMAC is safe where Hash(K‖M) is not.
Concept
Concept
Concept
Connect it up
Draw it
One page, no notation unless you need it: draw how these connect — What a MAC Is · When Is a MAC Secure? · Building One: AES-EMAC · The Hash-Based MAC: HMAC · Why HMAC Over the Naive Tries. Put an arrow wherever one of them is what makes another possible, and label the arrow with why.
Recap
You can now define a MAC as a keyed deterministic checksum, run the send/verify flow, define security via the EUF-CMA forgery game, trace AES-EMAC with its two-key seal, build HMAC from NMAC using the ipad/opad transform, and explain why naive Hash(K‖M) is forgeable while HMAC is safe.
| Idea | § | The one-line version |
|---|---|---|
| What a MAC is | 8.1–8.2 | T = F(K, M): keyed, deterministic; integrity + authenticity, not secrecy |
| Verify flow | 8.2 | Send (M, T); Bob accepts iff F(K, M) = T |
| EUF-CMA | 8.3 | No forgery on a NEW message, even with chosen (M, T) pairs |
| AES-EMAC | 8.4 | S_i = AES_{K1}(S_{i-1} ⊕ P_i); seal T = AES_{K2}(S_n) |
| HMAC | 8.5 | H((K′⊕opad) ‖ H((K′⊕ipad) ‖ M)); ipad 0x36, opad 0x5c |
| Naive MACs | 8.5 | H(M) no key; H(K‖M) length-extension; H(M‖K) collisions |
Want this taught 1-on-1? Alexander tutors Computer Security — $55/session, free consultation.