CS 161, Lesson 17, in 51 slides. It covers the three core goals of cryptography - confidentiality, integrity, and authenticity - plus deniability, and lays out the two-by-two grid of scheme families, crossing symmetric against asymmetric with confidentiality against integrity. It is anchored to textbook sections 5.6 to 5.7.
Subject: Computer Security · 88 slides · applied lesson
Open the interactive version of this deck · Homework for this lesson
Title
CS 161 · Lesson 17 of 45
Confidentiality · integrity · authenticity · deniability — and the four scheme families
Objectives
Warm-up
Discussion prompt
Before we open L17 · Confidentiality, Integrity, Authenticity & the Scheme Families: without looking back, what was the main idea of L16 · Cryptography Intro: History, Definitions, Keys, 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 16, in 50 slides, opening the cryptography unit. It gives a brief history - the Caesar cipher, Enigma, and Shannon and DES - then explains why we need formal definitions, introduces the cast of Alice, Bob, Eve, and Mallory, and distinguishes symmetric from asymmetric keys. It is anchored to textbook sections 5.2 to 5.5.
Concept
Cryptography defends a message that Alice sends to Bob while an adversary watches the wire. Three distinct goals; three distinct attackers.
Then §5.7 crosses these goals with symmetric vs asymmetric keys to name the four families of schemes you will study for the rest of the unit.
Counterexample
Discussion prompt
Cryptography defends a message that Alice sends to Bob while an adversary watches the wire. Three distinct goals; three distinct attackers.
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.
Section
Part 1 · §5.6
Concept
Confidentiality prevents an adversary from reading data. Even if Eve sees every byte on the wire, she does not learn the contents of the message.
Confidentiality — The property that an adversary cannot learn the contents of a message — they may see that a message exists, but not what it says.
Intuition
Imagine Alice puts her message in a box, locks it with a key, and mails the box. Eve can carry the box, shake it, photograph it — but without the key she can't open it.
Bob has a matching key, so he unlocks the box and reads the message. The box is the encryption; the lock is the key; the locked box on the wire is what Eve sees.
Ask yourself: what does the lockbox NOT promise? Nothing stops Mallory from swapping the whole box for a different one. Confidentiality hides contents — it says nothing about tampering. Hold that thought.
Analogy
Discussion prompt
Explain §5.6 The lockbox 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:
Imagine Alice puts her message in a box, locks it with a key, and mails the box. Eve can carry the box, shake it, photograph it — but without the key she can't open it.
Concept
Plaintext — The original, unencrypted message — what Alice actually wants to say.
Ciphertext — The encrypted, scrambled message — what travels on the wire and what Eve sees.
Encrypt = scramble plaintext into ciphertext using a key. Decrypt = unscramble ciphertext back into plaintext using a key.
Definition probe
Sort into buckets
Every line below is part of the definition of Confidentiality or of Plaintext — one or the other, never both. Put each where it belongs.
Ranking
Put in order
Put the moves of §5.6 The round trip: plaintext → ciphertext → plaintext 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 the secret Bob needs and Eve must not learn.
Worked example
Alice starts with plaintext: "attack at dawn"
Why: This is the secret Bob needs and Eve must not learn.
Alice runs Encrypt(key, plaintext) to get ciphertext
Why: The key scrambles the plaintext; the result is unreadable without the key.
Bob runs Decrypt(key, ciphertext) and recovers "attack at dawn"
Why: Decryption with the matching key inverts the scramble, returning the exact original plaintext.
| Stage | Held by | Visible to Eve? | Value |
|---|---|---|---|
| plaintext | Alice | no | "attack at dawn" |
| Encrypt(key, ·) | Alice | — | scramble |
| ciphertext | the wire | YES | unreadable blob |
| Decrypt(key, ·) | Bob | — | unscramble |
| plaintext | Bob | no | "attack at dawn" |
Comparison
Comparison matrix
From §5.6 The round trip: plaintext → ciphertext → plaintext: refill the Held by column from what you know. The rest of the table is as it appeared.
| Stage | Held by | Visible to Eve? | Value |
|---|---|---|---|
| plaintext | Alice | no | "attack at dawn" |
| Encrypt(key, ·) | Alice | — | scramble |
| ciphertext | the wire | YES | unreadable blob |
| Decrypt(key, ·) | Bob | — | unscramble |
| plaintext | Bob | no | "attack at dawn" |
Anomaly
Predict first
A student writes this, and it looks reasonable:
Alice encrypts "pay Bob $10" and sends the ciphertext. It arrives scrambled and unreadable to Eve.
It is wrong. Say what breaks — and say it before you turn the page.
Correct: Confuses HIDING the contents with PROTECTING the contents.
Alice encrypts "pay Bob $10" and sends the ciphertext. It arrives scrambled and unreadable to Eve.
Why: Confuses HIDING the contents with PROTECTING the contents. Encryption only controls who can read — not who can change.
Trap
Alice encrypts "pay Bob $10" and sends the ciphertext. It arrives scrambled and unreadable to Eve.
Conclude: since it's encrypted, Bob can trust it arrived exactly as Alice sent it
Why: Confuses HIDING the contents with PROTECTING the contents. Encryption only controls who can read — not who can change.
Mallory flips bits in the ciphertext; it still decrypts, now to "pay Bob $90"
Why: Many ciphers are malleable: changing the ciphertext changes the plaintext in predictable ways, and decryption happily produces garbage-or-worse with no alarm.
Alice encrypts "pay Bob $10" and sends the ciphertext. It arrives scrambled and unreadable to Eve.
Conclude: encryption gives confidentiality ONLY — Bob learns nothing about whether it was tampered with
Why: §5.6: encryption alone provides no integrity. This is THE central misconception of the unit.
To detect tampering, add a separate integrity mechanism (a tag) — that is a different goal
Why: Confidentiality and integrity are independent properties; you must build each one deliberately.
Concept
Encryption and decryption are two functions that invert each other under the same (symmetric) key.
\[ c = \mathrm{Enc}(k, m) \qquad m = \mathrm{Dec}(k, c) \]
Correctness: Dec(k, Enc(k, m)) = m for every message m. Confidentiality says: without k, the attacker learns essentially nothing about m from c.
Explain it
Discussion prompt
Explain §5.6 The encrypt/decrypt pair, formally 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:
Encryption and decryption are two functions that invert each other under the same (symmetric) key.
Concept
Confidentiality is narrow on purpose. Eve still learns some things even when she can't read the contents.
| Confidentiality hides | Confidentiality may NOT hide |
|---|---|
| the contents of the message | that a message was sent at all |
| what the plaintext says | the length of the message (roughly) |
| — | the timing and frequency of messages |
And crucially: it does NOT stop Mallory from CHANGING the ciphertext. Hiding ≠ protecting. That gap is the entire reason integrity is a separate goal.
Trade off
Comparison matrix
From §5.6 What confidentiality does NOT promise: every row here is a choice with a cost. Fill the Confidentiality may NOT hide column, then say which row you would actually pick and what you give up for it.
| Confidentiality hides | Confidentiality may NOT hide |
|---|---|
| the contents of the message | that a message was sent at all |
| what the plaintext says | the length of the message (roughly) |
| — | the timing and frequency of messages |
Intuition
By Kerckhoff's Principle (from L02's Shannon's Maxim), assume Eve knows the encryption ALGORITHM perfectly. The only thing she lacks is the key.
So confidentiality must rest entirely on the secrecy of the key, never on the secrecy of the lockbox design. A leaked key is cheap to rotate; a leaked algorithm is forever.
Ask yourself: if Eve knows the algorithm and can even guess the plaintext is one of two messages, what stops her from confirming which? (Randomized/probabilistic encryption — Goldwasser & Micali — so the same plaintext encrypts differently each time.)
Step zero
Discussion prompt
§5.6 What Eve can and cannot conclude — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.
Hint: It starts with: Eve intercepts a ciphertext blob on the wire
Answer:
Worked example
Eve intercepts a ciphertext blob on the wire
Why: She sees that Alice sent Bob SOMETHING, and roughly how long it is.
Eve tries to read the plaintext without the key
Why: Confidentiality means this fails — the contents stay hidden no matter how the ciphertext is analyzed.
Eve notes Alice messages Bob every day at 6am
Why: Traffic analysis: confidentiality of CONTENTS does not hide METADATA. Eve learns a pattern even without the words.
Blank canvas
Draw it
Draw what §5.6 What Eve can and cannot conclude 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.
Section
Part 2 · §5.6
Concept
Integrity prevents an adversary from tampering with a message undetected. If a message has integrity, an attacker cannot change its contents without being caught.
Integrity — The property that any modification of a message by an adversary is detectable — Bob will know if what arrived is not what Alice sent.
Intuition
Picture Alice sealing the envelope flap with a special tape that she can make and Bob can recognize — but Mallory cannot reproduce without Alice's key.
If Mallory steams the envelope open to alter the letter, the seal tears. He cannot forge a fresh, intact seal because he lacks the key. Bob checks the seal BEFORE trusting the contents.
Notice: the seal does NOT hide the letter. Integrity and confidentiality are orthogonal — a sealed clear envelope is readable but tamper-evident; a locked opaque box is hidden but swappable.
Step zero
Discussion prompt
§5.6 Tag generation and verification — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.
Hint: It starts with: Alice computes a tag t = Tag(key, message) and sends (message, t)
Answer:
Worked example
Alice computes a tag t = Tag(key, message) and sends (message, t)
Why: The tag is a short value that depends on both the message and the secret key — a fingerprint only a key-holder can produce.
Bob receives (message', t') and recomputes Verify(key, message', t')
Why: Bob re-derives what the tag SHOULD be for the message he got and compares; only a matching key-and-message pair verifies.
If Mallory changed the message, the tag no longer matches → reject
Why: Changing the message changes the correct tag, and Mallory can't compute a valid new tag without the key, so verification fails and the tamper is caught.
| Party | Has key? | Action | Outcome |
|---|---|---|---|
| Alice | yes | Tag(key, m) → t | valid tag produced |
| Mallory | no | edits m → m', wants new t' | cannot forge a valid t' for m' |
| Bob | yes | Verify(key, m', t') | match → accept; mismatch → reject |
Concept
The four combinations are all real, and you choose them independently per message.
| Confidential? | Integrity? | Real example |
|---|---|---|
| yes | yes | an encrypted, MAC'd bank instruction (what you want) |
| yes | no | encrypt-only ciphertext — secret but malleable |
| no | yes | a public software release with a signature |
| no | no | a plain postcard — readable and forgeable |
Anomaly
Predict first
A student writes this, and it looks reasonable:
To protect a message from tampering, append a CRC32 (or any keyless checksum) and have Bob recompute it.
It is wrong. Say what breaks — and say it before you turn the page.
Correct: Checksums detect ACCIDENTAL corruption, not a malicious Mallory — he edits the message AND recomputes the checksum, since it needs no secret.
To protect a message from tampering, append a CRC32 (or any keyless checksum) and have Bob recompute it.
Why: Checksums detect ACCIDENTAL corruption, not a malicious Mallory — he edits the message AND recomputes the checksum, since it needs no secret.
Trap
To protect a message from tampering, append a CRC32 (or any keyless checksum) and have Bob recompute it.
Treat a keyless checksum as a tamper-detector against an adversary
Why: Checksums detect ACCIDENTAL corruption, not a malicious Mallory — he edits the message AND recomputes the checksum, since it needs no secret.
To protect a message from tampering, append a CRC32 (or any keyless checksum) and have Bob recompute it.
Use a keyed tag (a MAC): the correct tag depends on a secret Mallory does not have
Why: §5.6: integrity against an adversary requires a key, so Mallory cannot forge a matching tag for his altered message. Checksums fight noise, MACs fight attackers.
Section
Part 3 · §5.6
Concept
Authenticity lets us determine who created a message. It is not enough that the message is unchanged — we want to know it genuinely came from Alice, not an impostor.
Authenticity — The property that lets the receiver determine the true origin (creator) of a message.
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 Confidentiality, Plaintext, Ciphertext, Integrity, Authenticity as L17 · Confidentiality, Integrity, Authenticity & the Scheme Families uses them. Pairing them correctly is the test of whether you could state each one with the slide switched off.
Intuition
The book's nuance: authenticity and integrity are closely related — "before you can prove authenticity, you first have to be able to prove integrity."
Why? If a message can be silently altered in transit, then 'it came from Alice' is meaningless — Alice's words might have been swapped for someone else's. You can only meaningfully attribute a message you know wasn't changed.
But they are NOT identical: edge cases exist where you have one without the full other. Treat authenticity as built ON integrity, not equal to it.
Concept
Most integrity and authenticity schemes work the same way: Alice generates a tag or signature over the message; Bob verifies it.
If the message was modified, the tag no longer verifies. And the attacker can't generate valid tags for malicious messages of their own — that is what attribution rests on.
Sorting
Sort into buckets
These are the pieces of L17 · Confidentiality, Integrity, Authenticity & the Scheme Families, out of order. Put each one back under the part of the lesson it belongs to.
Hypothesis
Predict first
§5.6 Verifying who sent it is about to be worked. State your hypothesis first: which rule or definition decides this one, and what is the first move it forces? Then watch whether the example agrees with you.
Correct: Alice tags m with a secret only she (and Bob, in the symmetric case) holds
Why: Because the tag requires the secret, a valid tag is evidence the message came from a holder of that secret.
A hypothesis you wrote down is falsifiable; a vague sense of how it will go is not. If the example opens somewhere else, that gap is the thing worth chasing.
Worked example
Alice tags m with a secret only she (and Bob, in the symmetric case) holds
Why: Because the tag requires the secret, a valid tag is evidence the message came from a holder of that secret.
Bob verifies the tag and it checks out
Why: A valid tag means two things at once: the message wasn't altered (integrity) AND it came from a key-holder (authenticity).
An impostor with no key tries to send (m'', t''); verification fails
Why: Without the secret the attacker cannot produce a tag that verifies, so Bob rejects the forgery — that is authenticity doing its job.
Trap
A student says: 'If a message is unchanged, then I know who sent it — same property, two names.'
Treat integrity and authenticity as one identical guarantee
Why: Conflates 'not modified' with 'created by Alice.' A message can be unmodified yet of unknown or wrong origin.
A student says: 'If a message is unchanged, then I know who sent it — same property, two names.'
They are closely related but DISTINCT: integrity = not-modified; authenticity = known-creator
Why: §5.6: you must prove integrity before authenticity, but proving content is intact is not the same as proving who produced it. Edge cases separate them.
Concept
We can write the two halves of any tag scheme as functions. Tagging takes a key and a message; verification re-derives and compares.
\[ t = \mathrm{Tag}(k, m) \qquad \mathrm{Verify}(k, m, t) \in \{\text{accept}, \text{reject}\} \]
Security goal: without k, an attacker cannot produce any new pair (m', t') that verifies — even after seeing many valid pairs. That single property is what buys both integrity and authenticity.
Intuition
The book warns the two are 'closely related but not identical.' Here's the flavor of a gap.
Suppose a tag proves a message wasn't altered after creation, but several parties share the key. You have INTEGRITY (it's unmodified) yet weak AUTHENTICITY (you can't single out WHICH key-holder wrote it) — the same ambiguity we'll formalize as deniability next.
Takeaway: build integrity first; authenticity layers on top, and how cleanly it does depends on who holds the key.
Section
Part 4 · §5.6
Concept
If a cryptosystem has deniability, there is no cryptographic proof that a message came from a particular person. A valid tag is not a smoking gun pinning the message on one author.
Deniability — The property that no cryptographic evidence ties a message to a specific sender — the sender can plausibly deny having created it.
Intuition
Suppose Alice and Bob share the SAME key to generate tags. A valid tag proves only that SOMEONE with that key made it — and two people hold it.
So if a message turns up with a valid tag, you cannot tell whether Alice made it or Bob made it. Either could have. That ambiguity IS deniability.
Explain it
Discussion prompt
Explain §5.6 The shared-key problem 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:
Suppose Alice and Bob share the SAME key to generate tags. A valid tag proves only that SOMEONE with that key made it — and two people hold it.
Ranking
Put in order
Put the moves of §5.6 Alice publishes to a judge 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. Symmetric tagging: both parties can both generate and verify tags with the identical secret.
Worked example
Alice and Bob share one key k used to make tags
Why: Symmetric tagging: both parties can both generate and verify tags with the identical secret.
Alice publishes a message m with a valid tag t = Tag(k, m), claiming Bob wrote it
Why: The tag verifies under k, so it looks authentic to anyone who can check — including a court.
A judge asks: did this come from Bob?
Why: The judge wants to attribute the message to a single author and hold him responsible.
The judge CANNOT be sure: Alice could have made the tag herself
Why: Because Alice also holds k, she is equally capable of producing t. A valid tag does not distinguish Alice from Bob — the message is deniable.
| Who could have made tag t? | Holds k? | Judge can rule out? |
|---|---|---|
| Bob | yes | no |
| Alice | yes | no |
| A stranger | no | yes |
Foreshadow: this is exactly why MACs (shared key, deniable) differ from digital signatures (private key, non-repudiable)
Why: Signatures use a secret only ONE person holds, so they DO pin authorship — non-repudiation. You'll meet that contrast in L23/L30.
Comparison
Comparison matrix
From §5.6 Alice publishes to a judge: refill the Holds k? column from what you know. The rest of the table is as it appeared.
| Who could have made tag t? | Holds k? | Judge can rule out? |
|---|---|---|
| Bob | yes | no |
| Alice | yes | no |
| A stranger | no | yes |
Concept
Deniability has a mirror image. Non-repudiation means a sender CANNOT later deny having created a message — there IS cryptographic proof of authorship.
| Property | Key model | Proof of single author? | Example |
|---|---|---|---|
| Deniability | shared key (symmetric) | no — either holder could've made it | MAC |
| Non-repudiation | private key (asymmetric) | yes — only one person holds the key | digital signature |
Which one you WANT depends on context: a whistleblower wants deniability; a signed contract wants non-repudiation. Neither is universally 'better' — and that's why both scheme families exist.
Analogy
Discussion prompt
Explain §5.6 Deniability vs non-repudiation 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:
Which one you WANT depends on context: a whistleblower wants deniability; a signed contract wants non-repudiation. Neither is universally 'better' — and that's why both scheme families exist.
Anomaly
Predict first
A student writes this, and it looks reasonable:
An engineer sees that a MAC can't prove who sent a message and files it as a security bug to be patched.
It is wrong. Say what breaks — and say it before you turn the page.
Correct: Treats a deliberate property as a defect.
An engineer sees that a MAC can't prove who sent a message and files it as a security bug to be patched.
Why: Treats a deliberate property as a defect. Forcing non-repudiation everywhere strips users of plausible deniability they may legitimately need.
Trap
An engineer sees that a MAC can't prove who sent a message and files it as a security bug to be patched.
Assume every scheme should prove authorship, so deniability must be eliminated
Why: Treats a deliberate property as a defect. Forcing non-repudiation everywhere strips users of plausible deniability they may legitimately need.
An engineer sees that a MAC can't prove who sent a message and files it as a security bug to be patched.
Recognize deniability as a chosen FEATURE of shared-key schemes; pick signatures only when non-repudiation is the actual requirement
Why: §5.6: there's no cryptographic proof of a single author by design. Whether that's good or bad depends entirely on the goal — it is not a bug.
Break the constraint
Discussion prompt
The rule this trap just fixed:
An engineer sees that a MAC can't prove who sent a message and files it as a security bug to be patched.
Now break it on purpose. Build a case that violates it and follow the consequences until something visibly fails. Where does the failure first show up — and would you have noticed it if you had not been looking?
Hint: The dangerous rules are the ones whose violation still produces an answer. If yours fails loudly, try to find one that fails quietly.
Answer:
Treats a deliberate property as a defect. Forcing non-repudiation everywhere strips users of plausible deniability they may legitimately need.
Section
Part 5 · §5.7
Concept
Every scheme answers two questions. Which goal? confidentiality, or integrity-&-authenticity. Which key model? symmetric (shared key) or asymmetric (public/private keypair).
Crossing those two binary choices gives a 2×2 — four families that organize the entire rest of the unit.
Counterexample
Discussion prompt
Every scheme answers two questions. Which goal? confidentiality, or integrity-&-authenticity. Which key model? symmetric (shared key) or asymmetric (public/private keypair).
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.
Answer:
Crossing those two binary choices gives a 2×2 — four families that organize the entire rest of the unit.
Worked example
Read the rows as the GOAL and the columns as the KEY MODEL
Why: Each cell names the primitive family that achieves that goal under that key model, with a canonical example.
| Goal ↓ / Keys → | Symmetric (shared key) | Asymmetric (public/private) |
|---|---|---|
| Confidentiality | Block ciphers + chaining modes (e.g. AES-CBC) | Public-key encryption (e.g. El Gamal, RSA) |
| Integrity & authenticity | MACs (e.g. AES-CBC-MAC) | Digital signatures (e.g. RSA signatures) |
Memorize the four cell names: block ciphers, public-key encryption, MACs, digital signatures
Why: Confidentiality lives in the top row, integrity/authenticity in the bottom; symmetric on the left, asymmetric on the right. These four names ARE the unit map.
Trade off
Comparison matrix
From §5.7 The 2×2 table: every row here is a choice with a cost. Fill the Asymmetric (public/private) column, then say which row you would actually pick and what you give up for it.
| Goal ↓ / Keys → | Symmetric (shared key) | Asymmetric (public/private) |
|---|---|---|
| Confidentiality | Block ciphers + chaining modes (e.g. AES-CBC) | Public-key encryption (e.g. El Gamal, RSA) |
| Integrity & authenticity | MACs (e.g. AES-CBC-MAC) | Digital signatures (e.g. RSA signatures) |
Concept
Some primitives don't directly provide confidentiality, integrity, or authenticity — but they are the building blocks that make secure systems possible.
Matching
Match the pairs
From §5.7 The helper primitives — match each one to what it actually does. The descriptions have been shuffled.
Why: Cryptographic hashes, PRNGs, Key exchange are easy to tell apart while they are sitting next to their descriptions and much harder afterwards, which is what this checks.
Step zero
Discussion prompt
§5.7 Picking a family from a goal — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.
Hint: It starts with: Goal: "Bob must detect any tampering AND know the message is from…
Answer:
Worked example
Goal: "Bob must detect any tampering AND know the message is from Alice, and they already share a key."
Why: Tampering-detection + origin = integrity & authenticity. A shared key = symmetric. Two coordinates fixed.
Locate the cell: bottom row (integrity/authenticity), left column (symmetric)
Why: Walking the 2×2 with those two coordinates lands you in exactly one box.
Answer: a MAC (e.g. AES-CBC-MAC)
Why: MACs give symmetric integrity & authenticity. Not encryption (wrong goal), not a signature (that's the asymmetric cell).
Concept
Symmetric — Both parties share the SAME secret key, used for both directions (encrypt/decrypt, or tag/verify). Fast, but you must distribute the shared key.
Asymmetric — Each party has a public/private KEYPAIR. One key does the operation, its partner reverses it — no shared secret needed up front.
That single axis (shared key vs keypair) is the column you pick in the 2×2 — and it's also why MACs are deniable (shared key) while signatures are not (private key held by one person).
Intuition
The three goals line up cleanly with three letters of STRIDE from L03's threat modeling.
| STRIDE threat | Defeats it | Family |
|---|---|---|
| Information disclosure | Confidentiality | Encryption (block cipher / public-key) |
| Tampering | Integrity | MAC / digital signature |
| Spoofing | Authenticity | MAC / digital signature |
So the 2×2 isn't abstract bookkeeping — each cell is the tool you reach for when a specific STRIDE threat shows up in a design review.
Comparison
Comparison matrix
From §5.7 The 2×2 mapped to STRIDE: refill the Family column from what you know. The rest of the table is as it appeared.
| STRIDE threat | Defeats it | Family |
|---|---|---|
| Information disclosure | Confidentiality | Encryption (block cipher / public-key) |
| Tampering | Integrity | MAC / digital signature |
| Spoofing | Authenticity | MAC / digital signature |
Step zero
Discussion prompt
§5.7 A second family pick: public software release — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.
Hint: It starts with: Goal: anyone on the internet must verify a download came from the…
Answer:
Worked example
Goal: anyone on the internet must verify a download came from the vendor, unmodified — no shared key with each user
Why: Integrity & authenticity (bottom row); no pre-shared secret with millions of strangers means asymmetric (right column).
Locate the cell: bottom row, right column
Why: Two coordinates → exactly one box in the 2×2.
Answer: a digital signature (e.g. RSA signature)
Why: The vendor signs with a private key; everyone verifies with the public key. A MAC fails here — you can't share one secret with the whole world, and you'd want non-repudiation anyway.
Anomaly
Predict first
A student writes this, and it looks reasonable:
Goal: let Bob detect if Mallory tampered with a message in transit.
It is wrong. Say what breaks — and say it before you turn the page.
Correct: Mallory can change the message AND recompute hash(message') — a plain hash has no secret, so anyone can forge a matching digest.
Goal: let Bob detect if Mallory tampered with a message in transit.
Why: Mallory can change the message AND recompute hash(message') — a plain hash has no secret, so anyone can forge a matching digest.
Trap
Goal: let Bob detect if Mallory tampered with a message in transit.
Send (message, hash(message)) and have Bob recompute the hash to check
Why: Mallory can change the message AND recompute hash(message') — a plain hash has no secret, so anyone can forge a matching digest.
Goal: let Bob detect if Mallory tampered with a message in transit.
Use a MAC: send (message, MAC(key, message)) — the tag depends on a SECRET key
Why: §5.7: a hash is a keyless helper; a MAC is keyed. Only the key-holders can produce a valid tag, so Mallory cannot re-forge it. A hash ≠ a MAC.
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student wants authenticity, so they 'encrypt the message with Alice's private key.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: Mixes two different goals and key directions.
A student wants authenticity, so they 'encrypt the message with Alice's private key.'
Why: Mixes two different goals and key directions. A signature targets integrity/authenticity, NOT confidentiality, and modern signatures are not 'encryption backwards.'
Trap
A student wants authenticity, so they 'encrypt the message with Alice's private key.'
Treat signing = encrypting and assume it also hides the message
Why: Mixes two different goals and key directions. A signature targets integrity/authenticity, NOT confidentiality, and modern signatures are not 'encryption backwards.'
A student wants authenticity, so they 'encrypt the message with Alice's private key.'
Use a digital signature for authenticity; use public-key encryption (a separate primitive) if you also need confidentiality
Why: §5.7: signatures and public-key encryption are different cells of the 2×2. Signing proves origin; it does not conceal contents. Pick the cell that matches the goal.
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.
Ranking
Put in order
Put the moves of §5.7 A third pick: keep a chat secret between two phones 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. Unreadable = confidentiality (top row).
Worked example
Goal: two phones that already ran a key exchange want their chat unreadable to the carrier
Why: Unreadable = confidentiality (top row). They share a key from the exchange = symmetric (left column).
Locate the cell: top row, left column
Why: Confidentiality + symmetric.
Answer: a block cipher in a chaining mode (e.g. AES-CBC) — and add a MAC if they also need tamper-detection
Why: Encryption gives the secrecy they asked for; if integrity matters too, that's a SECOND mechanism, never assumed from encryption alone (→ AEAD, L24).
Blank canvas
Draw it
Draw what §5.7 A third pick: keep a chat secret between two phones 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
Four families plus three helpers — that is the whole crypto unit on one slide. Every later lesson lives in one of these boxes.
Constraint
Discussion prompt
Run The goal-to-family decision procedure with this step confiscated:
Read off the cell. Confidentiality+symmetric → block cipher mode (AES-CBC); confidentiality+asymmetric → public-key encryption; integrity+symmetric → MAC; integrity+asymmetric → digital signature.
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 goal-to-family decision procedure 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
What does encrypting (and nothing else) guarantee here?
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: §5.6: encryption provides confidentiality only. It hides the contents from Mallory but gives no integrity — many ciphers are malleable, so Mallory can alter the ciphertext and Bob has no built-in way to detect it. Detecting tampering requires a separate integrity mechanism (a MAC or a signature).
Check
Alice encrypts a wire-transfer instruction with AES and sends only the ciphertext to Bob (no separate tag). Mallory sits on the wire.
Check your understanding
What does encrypting (and nothing else) guarantee here?
Answer: A
Why: §5.6: encryption provides confidentiality only. It hides the contents from Mallory but gives no integrity — many ciphers are malleable, so Mallory can alter the ciphertext and Bob has no built-in way to detect it. Detecting tampering requires a separate integrity mechanism (a MAC or a signature).
Concept
Concept
Concept
Connect it up
Draw it
One page, no notation unless you need it: draw how these connect — Confidentiality: Don't Read It · Integrity: Don't Change It Undetected · Authenticity: Who Wrote It? · Deniability: A Feature, Not a Bug · The Four Scheme Families. Put an arrow wherever one of them is what makes another possible, and label the arrow with why.
Recap
You can now name each goal by the attacker capability it denies, explain why encryption alone gives no integrity, walk the deniability scenario, and drop any goal into the right cell of the 2×2.
| Property | Denies the attacker… | Built with |
|---|---|---|
| Confidentiality | READING the contents | Encryption (sym: AES-CBC; asym: RSA/El Gamal) |
| Integrity | TAMPERING undetected | Tags: MAC (sym) / signature (asym) |
| Authenticity | FORGING the author (built on integrity) | MAC (sym) / digital signature (asym) |
| Deniability | PROVING a single author (a feature) | Shared-key tags (MACs) |
Want this taught 1-on-1? Alexander tutors Computer Security — $55/session, free consultation.