CS 161, Lesson 29, in 51 slides. It covers the public-key distribution problem and the Attila key-substitution attack, in section 11.5, then why public-key cryptography is too slow to encrypt data directly and how hybrid encryption with session keys and its four-key setup solves that, in section 11.6. Supplemental material covers KEM and DEM, post-quantum cryptography, and Shor's and Grover's algorithms. It is anchored to textbook sections 11.5 to 11.6.
Subject: Computer Security · 83 slides · applied lesson
Open the interactive version of this deck · Homework for this lesson
Title
CS 161 · Lesson 29 of 45
the public-key distribution problem · why RSA is too slow for data · hybrid encryption & session keys · plus KEM/DEM and the post-quantum future
Objectives
Warm-up
Discussion prompt
Before we open L29 · Public-Key Distribution, Hybrid Encryption & Session Keys: without looking back, what was the main idea of L28 · Public-Key Encryption: Trapdoor Functions, RSA & El Gamal, 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 28, in 50 slides. It explains why asymmetric cryptography solves the pre-shared-key problem, in section 11.1, then covers trapdoor one-way functions and the hard problems behind RSA and discrete log, in section 11.2. It covers RSA encryption and why textbook RSA is deterministic and therefore not IND-CPA without OAEP padding, in section 11.3, and El Gamal encryption built on Diffie-Hellman, with a fully worked toy example, in section 11.4. It is anchored to textbook sections 11.1 to 11.4.
Concept
L27–L28 built public-key tools (Diffie-Hellman, RSA, El Gamal). This lesson asks the two practical questions that turn those tools into a real system: how does Alice get Bob's key, and how do we actually encrypt data with it?
Matching
Match the pairs
From Where this lesson sits — match each one to what it actually does. The descriptions have been shuffled.
Why: How does Alice get Bob's key?, Why not encrypt data directly?, What real systems do 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 · §11.5 getting Bob's authentic key
Concept
Public-key crypto sounds too good to be true: anyone can encrypt to Bob using a key he publishes, with no shared secret needed. There IS a catch — and it is not in the encryption algorithm.
The catch: how does Alice learn Bob's authentic public key in the first place? The cleverest cipher in the world doesn't help if Alice encrypts to the wrong key.
Counterexample
Discussion prompt
Public-key crypto sounds too good to be true: anyone can encrypt to Bob using a key he publishes, with no shared secret needed. There IS a catch — and it is not in the encryption algorithm.
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:
The catch: how does Alice learn Bob's authentic public key in the first place? The cleverest cipher in the world doesn't help if Alice encrypts to the wrong key.
Concept
RSA, El Gamal, DH — none of them tell Alice WHICH public key belongs to Bob. They assume she already has it. Establishing that mapping is a separate problem.
Public-key distribution problem — The problem of getting a party's authentic public key to everyone who needs it. The encryption algorithms presuppose a solution; they do not provide one.
Analogy
Discussion prompt
Explain §11.5 What the algorithms can't solve 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:
RSA, El Gamal, DH — none of them tell Alice WHICH public key belongs to Bob. They assume she already has it. Establishing that mapping is a separate problem.
Intuition
A public key is, by definition, public — there's nothing secret about it. So the channel Alice uses to learn it doesn't need confidentiality.
What it DOES need is integrity / authenticity: a guarantee that the key she receives really is Bob's and wasn't swapped out in transit. The whole difficulty lives there.
Ask yourself: if the key is already public, what could an attacker possibly gain by tampering with it? (Substitute his OWN key, so Alice unknowingly encrypts to him.)
Explain it
Discussion prompt
Explain §11.5 Integrity, not confidentiality, is what's missing 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 public key is, by definition, public — there's nothing secret about it. So the channel Alice uses to learn it doesn't need confidentiality.
Concept
The obvious idea: Bob simply broadcasts his public key to the world. Anyone who wants to message him grabs it and encrypts. What could go wrong?
Everything — if the attacker is active. Against a passive eavesdropper a broadcast key is fine. Against an attacker who can modify traffic, broadcasting alone is fatally broken.
Concept
Attila — An active attacker on the channel who can intercept, drop, modify, and inject messages — not merely eavesdrop. He can replace a broadcast public key with one of his own choosing.
When Bob broadcasts his key, Attila intercepts it and broadcasts his own public key, claiming it is Bob's. Alice has no way to tell the difference.
Definition probe
Sort into buckets
Every line below is part of the definition of Public-key distribution problem or of Attila — one or the other, never both. Put each where it belongs.
Intuition
Alice receives a public key labeled 'Bob.' It's a perfectly valid public key — it encrypts and decrypts correctly. Nothing about the key itself reveals whose it really is.
She encrypts her secret message under it and sends. Attila intercepts the ciphertext, decrypts it with his matching private key, reads it, and (if he likes) re-encrypts under Bob's real key and forwards.
Ask yourself: what proof does Alice have that the key is Bob's? (None — a raw public key carries no identity binding. That's exactly what certificates will fix in L31.)
Ranking
Put in order
Put the moves of §11.5 Walk the Attila key-substitution attack 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. Broadcast gives confidentiality of the message to whoever holds the matching private key — but provides no integrity on the key value itself.
Worked example
Setup: Bob broadcasts his real public key PK_B; Attila controls the channel
Why: Broadcast gives confidentiality of the message to whoever holds the matching private key — but provides no integrity on the key value itself.
Attila intercepts PK_B and sends Alice his OWN key PK_M, labeled 'Bob'
Why: Alice has no authentic reference for Bob's key, so a valid-looking substitute is indistinguishable from the genuine one.
Alice encrypts her message under PK_M and sends the ciphertext
Why: She believes she is encrypting to Bob; the cipher works flawlessly — on the wrong key.
| Step | What happens | What Alice believes |
|---|---|---|
| Bob broadcasts PK_B | Attila intercepts it | (she never sees it) |
| Attila sends PK_M | labeled as 'Bob' | this is Bob's key |
| Alice encrypts under PK_M | ciphertext → Attila | only Bob can read this |
| Attila decrypts with SK_M | reads the plaintext | the message is private |
Verify: Attila reads the plaintext; he may re-encrypt under real PK_B and forward to Bob undetected
Why: §11.5: with no integrity on the key, the substitution is a man-in-the-middle. Both Alice and Bob can be left believing the channel is private.
Comparison
Comparison matrix
From §11.5 Walk the Attila key-substitution attack: refill the What happens column from what you know. The rest of the table is as it appeared.
| Step | What happens | What Alice believes |
|---|---|---|
| Bob broadcasts PK_B | Attila intercepts it | (she never sees it) |
| Attila sends PK_M | labeled as 'Bob' | this is Bob's key |
| Alice encrypts under PK_M | ciphertext → Attila | only Bob can read this |
| Attila decrypts with SK_M | reads the plaintext | the message is private |
Concept
How do people actually establish authentic keys today, without a full system? A few low-tech approaches, each requiring you to have met first:
All of these need a prior in-person channel — they don't scale to strangers on the open Internet. That motivates certificates and PKI (L31).
Intuition
This should feel familiar: it's the L27 Diffie-Hellman man-in-the-middle in a new costume. There, Mallory substituted her own g^m; here, Attila substitutes his own public key.
The common root cause is identical: a key value travels with no proof of WHO sent it. Authenticity of the key material is the missing ingredient in both attacks.
Ask yourself: did the attacker break any encryption to win? (No — both attacks bypass the math entirely by corrupting the key-distribution step.)
Step zero
Discussion prompt
§11.5 A partial fix in practice: verify a fingerprint — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.
Hint: It starts with: Bob computes a short fingerprint: H = hash of his public key, read…
Answer:
Worked example
Bob computes a short fingerprint: H = hash of his public key, read aloud as hex words
Why: A full 2048-bit key is too long to compare by eye, but a hash compresses it to a short, comparable string.
Alice and Bob compare the fingerprint over an authenticated out-of-band channel (in person, or a known voice on the phone)
Why: The out-of-band channel supplies the integrity the open network lacked — Attila can't forge Bob's voice in person.
| Channel | Confidential? | Authentic? | Use for |
|---|---|---|---|
| Open Internet | no | no | bulk key transport (but unverified) |
| In person / known voice | n/a | yes | verifying the fingerprint |
Verify: if the fingerprints match, the key Alice holds is genuinely Bob's; if Attila swapped it, the fingerprints differ
Why: §11.5: the comparison detects substitution because it rides an authentic channel — exactly why these manual fixes need prior in-person contact and don't scale.
Trade off
Comparison matrix
From §11.5 A partial fix in practice: verify a fingerprint: every row here is a choice with a cost. Fill the Use for column, then say which row you would actually pick and what you give up for it.
| Channel | Confidential? | Authentic? | Use for |
|---|---|---|---|
| Open Internet | no | no | bulk key transport (but unverified) |
| In person / known voice | n/a | yes | verifying the fingerprint |
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'A public key is meant to be public, so it doesn't matter if an attacker sees or relays it — broadcasting it is totally safe.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: Secrecy was never the concern. With no INTEGRITY, an active attacker (Attila) swaps in his own key — Alice encrypts to him.
A student: what property does key distribution actually require?
Why: Secrecy was never the concern. With no INTEGRITY, an active attacker (Attila) swaps in his own key — Alice encrypts to him. 'Public' does not mean 'authentic.'
Trap
A student: 'A public key is meant to be public, so it doesn't matter if an attacker sees or relays it — broadcasting it is totally safe.'
Conclude that 'public' implies 'safe to distribute over any channel'
Why: Wrong. Secrecy was never the concern. With no INTEGRITY, an active attacker (Attila) swaps in his own key — Alice encrypts to him. 'Public' does not mean 'authentic.'
A student: what property does key distribution actually require?
Recognize the channel must guarantee INTEGRITY / AUTHENTICITY of the key, not confidentiality
Why: §11.5: the key need not be hidden, but Alice must be sure it is Bob's and unmodified. Without that, broadcast enables key-substitution / MITM.
Section
Part 2 · §11.6 don't encrypt data directly
Concept
Suppose Alice DOES have Bob's authentic key. Can she just RSA-encrypt her whole file? Technically yes — but it would be painfully slow.
Public-key operations are built on big-number arithmetic that costs orders of magnitude more than a symmetric cipher per byte. We need to know HOW much more.
Concept
Encrypting one message with a 2048-bit RSA key means raising a 2048-bit number to a 2048-bit power, modulo a 2048-bit number.
\[ c = m^{e} \bmod n, \quad m,e,n \approx 2048 \text{ bits} \]
Even with repeated squaring, that's thousands of 2048-bit modular multiplications — for ONE message block. Symmetric AES processes a block in a handful of cheap operations.
Intuition
AES works on small fixed-size blocks with table lookups, XORs, and bit shuffles — operations a CPU does in nanoseconds, often with hardware acceleration.
RSA works on huge integers; each modular multiplication touches hundreds of machine words. The gap is typically thousands of times slower per byte for public-key crypto.
Ask yourself: if asymmetric crypto is so expensive, why use it at all? (For one thing only — distributing a key without a prior shared secret. Then hand off to fast symmetric crypto.)
Step zero
Discussion prompt
§11.6 Estimate the cost gap on a real file — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.
Hint: It starts with: A 2048-bit RSA key encrypts at most ~245 bytes per operation (after…
Answer:
Worked example
A 2048-bit RSA key encrypts at most ~245 bytes per operation (after padding)
Why: RSA can only encrypt a message smaller than its modulus, so each operation handles a couple hundred bytes — not megabytes.
Count operations for a 50 MB file: 50,000,000 ÷ ~245 ≈ 200,000 RSA operations
Why: Each ~245-byte chunk needs its own full modular exponentiation — and each is thousands of times slower than an AES block.
\[ \frac{50{,}000{,}000 \text{ bytes}}{\sim 245 \text{ bytes/op}} \approx 200{,}000 \text{ RSA ops} \]
Verify: ~200,000 heavy modular exponentiations vs ONE for hybrid — the gap is enormous
Why: §11.6: hybrid needs a single RSA operation (to wrap the session key) regardless of file size; direct RSA scales linearly with a thousand-fold-heavier primitive. That's why nobody RSAs the file.
Notation
Annotate
From §11.6 Estimate the cost gap on a real file — read this one piece at a time. What is each part doing?
On: \( \frac{50{,}000{,}000 \text{ bytes}}{\sim 245 \text{ bytes/op}} \approx 200{,}000 \text{ RSA ops} \)
Concept
Speed isn't the only issue. Some public-key schemes are only safe when the message being encrypted is random, not meaningful structured data.
Step zero
Discussion prompt
§11.6 See the El Gamal m → 2m malleability — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.
Hint: It starts with: Setup: in simplified El Gamal a message m is sent as a ciphertext…
Answer:
Worked example
Setup: in simplified El Gamal a message m is sent as a ciphertext that includes the product m · s, where s is a per-message shared secret
Why: The message is blended multiplicatively with a secret value; the attacker never learns m or s, but can still touch the product.
Attacker multiplies the message-carrying component by 2 in transit
Why: Multiplying m · s by 2 yields (2m) · s — the same valid form, now carrying 2m instead of m.
\[ (m \cdot s) \times 2 = (2m) \cdot s \]
Bob decrypts and recovers 2m instead of m, none the wiser
Why: The ciphertext is still well-formed, so decryption succeeds — the attacker silently doubled the message.
Verify: the attacker changed the plaintext without knowing it — so meaningful messages must NOT be encrypted with the plain scheme
Why: §11.6: malleability on structured data is exactly why we encrypt only RANDOM session keys with public-key crypto, where an undetected m→2m change is harmless.
Notation
Annotate
From §11.6 See the El Gamal m → 2m malleability — read this one piece at a time. What is each part doing?
On: \( (m \cdot s) \times 2 = (2m) \cdot s \)
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'I have Bob's RSA public key, so I'll just RSA-encrypt my entire 10 MB file and send it.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: Wrong on two counts: it's thousands of times too slow for megabytes, AND plain schemes are unsafe on meaningful data (deterministic RSA leaks repeats; El Gamal is malleable).
A student: what is public-key crypto actually for, then?
Why: Wrong on two counts: it's thousands of times too slow for megabytes, AND plain schemes are unsafe on meaningful data (deterministic RSA leaks repeats; El Gamal is malleable).
Trap
A student: 'I have Bob's RSA public key, so I'll just RSA-encrypt my entire 10 MB file and send it.'
Use public-key encryption directly on the bulk data
Why: Wrong on two counts: it's thousands of times too slow for megabytes, AND plain schemes are unsafe on meaningful data (deterministic RSA leaks repeats; El Gamal is malleable).
A student: what is public-key crypto actually for, then?
Use public-key crypto only to ship a small random session key; encrypt the file with fast symmetric crypto
Why: §11.6: this is hybrid encryption. Asymmetric handles key distribution; symmetric handles the bulk data — fast and safe.
Section
Part 3 · §11.6 the core construction
Concept
Use public-key crypto for the ONE thing it's good at — distributing a secret without a prior shared key — and use symmetric crypto for everything else.
Session key — A fresh, random symmetric key generated for a single session. The actual data is encrypted under it with fast symmetric crypto; the session key itself is shipped under the recipient's public key.
Concept
Hybrid encryption — Encrypt the data with a symmetric scheme under a random session key, then encrypt (wrap) the session key under the recipient's public key. Send both. Public-key crypto distributes the key; symmetric crypto carries the data.
This is not a compromise or a weaker option — it is how essentially ALL real public-key systems (TLS, PGP, encrypted email) actually work.
Intuition
A session key is tiny — 128 or 256 bits. Wrapping 128 random bits with ONE public-key operation is cheap. Wrapping a 10 MB file would be millions of operations.
And the session key is RANDOM, so the unsafe-on-structured-data problem evaporates: there's nothing meaningful for malleability or determinism to leak.
Ask yourself: how many public-key operations does hybrid encryption need, regardless of file size? (Just one — to wrap the session key. Everything else is fast symmetric crypto.)
Sorting
Sort into buckets
These are the pieces of L29 · Public-Key Distribution, Hybrid Encryption & Session Keys, out of order. Put each one back under the part of the lesson it belongs to.
Concept
Ranking
Put in order
Put the moves of §11.6 Construct a hybrid ciphertext 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 encryption is fast, so the bulk data costs almost nothing regardless of size; k is fresh per session.
Worked example
Alice generates a random session key k and encrypts the body: C = AES-128-CBC encryption of M under k
Why: Symmetric encryption is fast, so the bulk data costs almost nothing regardless of size; k is fresh per session.
Alice MACs the ciphertext: T = HMAC-SHA-256 over C under a separate MAC key
Why: Confidentiality alone isn't enough — a MAC gives integrity so tampering with C is detected (encrypt-then-MAC).
Alice wraps the session key(s) under Bob's public key: W = RSA-OAEP encryption of the keys under PK_B
Why: Only one public-key operation, and it encrypts random key bytes — fast and safe from malleability/determinism issues.
| Layer | Algorithm | Encrypts | Cost |
|---|---|---|---|
| Key-wrap (asymmetric) | RSA-OAEP under PK_B | the random session keys | one PK operation |
| Body (symmetric) | AES-128-CBC under k | the actual message M | fast, scales with size |
| Integrity (symmetric) | HMAC-SHA-256 | the ciphertext C | fast |
Verify: Bob unwraps the keys with SK_B, checks the MAC, then decrypts C — recovering M, with only one PK operation total
Why: §11.6: the ciphertext is two layers — PK-wrapped keys plus a symmetric-encrypted, MAC'd body. That is hybrid encryption end to end.
Comparison
Comparison matrix
From §11.6 Construct a hybrid ciphertext: refill the Cost column from what you know. The rest of the table is as it appeared.
| Layer | Algorithm | Encrypts | Cost |
|---|---|---|---|
| Key-wrap (asymmetric) | RSA-OAEP under PK_B | the random session keys | one PK operation |
| Body (symmetric) | AES-128-CBC under k | the actual message M | fast, scales with size |
| Integrity (symmetric) | HMAC-SHA-256 | the ciphertext C | fast |
Intuition
Think of the ciphertext as a sealed box (the symmetric body) plus a small locked envelope taped to it (the wrapped session key).
Only Bob's private key opens the envelope. Inside is the session key, which then unlocks the box. The box can be any size; the envelope is always tiny.
Ask yourself: what would Attila gain by stealing just the box without the envelope? (Nothing — without the session key inside the PK-wrapped envelope, the symmetric body is opaque.)
Concept
A real setup rarely uses a single session key. Recall the L24 rule: never reuse one key for two different jobs. That forces SEVERAL keys.
Explain it
Discussion prompt
Explain §11.6 One key is not enough — you need several 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 real setup rarely uses a single session key. Recall the L24 rule: never reuse one key for two different jobs. That forces SEVERAL keys.
Step zero
Discussion prompt
§11.6 Count to four keys — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.
Hint: It starts with: Start from two needs: confidentiality (enc) and integrity (MAC)
Answer:
Worked example
Start from two needs: confidentiality (enc) and integrity (MAC)
Why: Different cryptographic jobs must use different keys, so a single direction already needs two keys, not one.
Now double for the two directions: Alice→Bob and Bob→Alice
Why: Reusing the same keys both ways enables reflection/replay confusion, so each direction gets its own pair.
| Direction | Encryption key | MAC key |
|---|---|---|
| Alice → Bob | k_enc(A→B) | k_mac(A→B) |
| Bob → Alice | k_enc(B→A) | k_mac(B→A) |
\[ 2 \text{ jobs} \times 2 \text{ directions} = 4 \text{ symmetric keys} \]
Verify: a full bidirectional session needs FOUR symmetric keys, typically derived together and wrapped once under the public key
Why: §11.6: enc/MAC separation times two directions gives four keys — all generated as random session keys and distributed via the single public-key wrap.
Trade off
Comparison matrix
From §11.6 Count to four keys: every row here is a choice with a cost. Fill the Encryption key column, then say which row you would actually pick and what you give up for it.
| Direction | Encryption key | MAC key |
|---|---|---|
| Alice → Bob | k_enc(A→B) | k_mac(A→B) |
| Bob → Alice | k_enc(B→A) | k_mac(B→A) |
Concept
It's tempting to think wrapping a symmetric key 'downgrades' to symmetric security. It doesn't: an attacker must STILL break the public-key wrap to learn the session key.
Security is the minimum of the layers — and we deliberately match strengths (e.g. AES-128 with a 2048-bit RSA wrap, per L27's equivalence table). Hybrid is the standard, fully-secure design.
Analogy
Discussion prompt
Explain §11.6 Why hybrid is not weaker than 'pure' public-key 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:
Security is the minimum of the layers — and we deliberately match strengths (e.g. AES-128 with a 2048-bit RSA wrap, per L27's equivalence table). Hybrid is the standard, fully-secure design.
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'I'll generate one session key and use it for AES, for the MAC, and for both directions — simpler is better.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: Reusing a key for encryption and MAC, or across directions, breaks the L24 different-keys rule — it opens cross-protocol and reflection attacks.
A student: how many keys should a bidirectional session really use?
Why: Reusing a key for encryption and MAC, or across directions, breaks the L24 different-keys rule — it opens cross-protocol and reflection attacks. Confidentiality and integrity need distinct keys.
Trap
A student: 'I'll generate one session key and use it for AES, for the MAC, and for both directions — simpler is better.'
Reuse a single key across enc, MAC, and both directions
Why: Wrong. Reusing a key for encryption and MAC, or across directions, breaks the L24 different-keys rule — it opens cross-protocol and reflection attacks. Confidentiality and integrity need distinct keys.
A student: how many keys should a bidirectional session really use?
Use four: separate encryption and MAC keys, one pair per direction
Why: §11.6 (callback to L24): different keys for enc vs MAC and per direction — four symmetric keys, all carried by one public-key wrap.
Section
Part 4 · ⊕ supplemental — beyond the textbook
Concept
⊕ Supplemental (beyond this textbook). Modern cryptography formalizes hybrid encryption as two cleanly-separated pieces with precise names.
KEM (Key Encapsulation Mechanism) — ⊕ Takes the recipient's public key and outputs a pair (ciphertext, shared_secret). The ciphertext lets the recipient recover the same shared_secret with their private key. It's the formal version of 'wrap a random key.'
Concept
DEM (Data Encapsulation Mechanism) — ⊕ Takes the shared_secret from the KEM and encrypts the actual data with it using symmetric crypto (authenticated encryption). It's the formal version of 'now AES the message.'
\[ \text{KEM} + \text{DEM} = \text{hybrid encryption} \]
⊕ Cramer & Shoup (2003) introduced this framework. It's exactly the §11.6 construction, just named and proven cleanly so each half can be analyzed on its own.
Intuition
⊕ Splitting the scheme lets you prove security of the KEM and the DEM separately, then compose — far easier than analyzing a tangled whole.
⊕ It also makes the public-key part swappable. The DEM (AES) stays put; you can drop in a totally different KEM — including a post-quantum one — without touching the data layer.
Ask yourself: which half of KEM/DEM maps to the §11.6 'wrap the session key' step? (The KEM — it encapsulates the shared secret under the public key; the DEM is the symmetric body.)
Counterexample
Discussion prompt
Ask yourself: which half of KEM/DEM maps to the §11.6 'wrap the session key' step? (The KEM — it encapsulates the shared secret under the public key; the DEM is the symmetric body.)
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.
Ranking
Put in order
Put the moves of ⊕ Trace a message through KEM + DEM 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 KEM produces the shared secret directly from Bob's public key — no separate 'pick a key then encrypt it' step to get wrong.
Worked example
Sender runs KEM(PK_B) → (ct, ss): a ciphertext and a shared secret
Why: ⊕ The KEM produces the shared secret directly from Bob's public key — no separate 'pick a key then encrypt it' step to get wrong.
Sender runs DEM: encrypt the message under ss with authenticated symmetric encryption
Why: ⊕ The shared secret keys the fast symmetric layer carrying the actual data — the DEM half.
| Half | Input | Output |
|---|---|---|
| KEM | PK_B | (ct, ss) |
| DEM | ss + message | symmetric ciphertext |
| Recipient KEM⁻¹ | ct + SK_B | recovers ss |
| Recipient DEM⁻¹ | ss + ciphertext | recovers message |
Verify: Bob recovers ss from ct with his private key, then decrypts the body — identical outcome to §11.6 hybrid encryption
Why: ⊕ KEM + DEM IS the §11.6 construction; the formalism just names and isolates each half so each can be proven secure independently.
Comparison
Comparison matrix
From ⊕ Trace a message through KEM + DEM: refill the Input column from what you know. The rest of the table is as it appeared.
| Half | Input | Output |
|---|---|---|
| KEM | PK_B | (ct, ss) |
| DEM | ss + message | symmetric ciphertext |
| Recipient KEM⁻¹ | ct + SK_B | recovers ss |
| Recipient DEM⁻¹ | ss + ciphertext | recovers message |
Concept
⊕ Supplemental. RSA's security rests on factoring; DH/ECC rest on discrete log. A large fault-tolerant quantum computer breaks BOTH — via Shor's algorithm (1994), which efficiently factors and solves discrete log.
Shor's algorithm — ⊕ A quantum algorithm that factors integers and computes discrete logs in polynomial time. It would break RSA, finite-field DH, and elliptic-curve crypto — the public-key foundations of L27–L28.
Concept
⊕ Quantum computing does NOT break symmetric crypto the same way. The relevant tool, Grover's algorithm, only gives a quadratic speedup on brute-force search.
\[ 2^{n} \ \xrightarrow{\text{Grover}}\ 2^{n/2} \]
⊕ A quadratic speedup just halves the effective key length. The fix is trivial: double the key. AES-256 keeps ~128-bit security against Grover; SHA stays strong with longer outputs.
Concept
⊕ Because Shor breaks RSA/ECC, NIST ran a multi-year post-quantum standardization. The winners are lattice-based — a hard problem with no known efficient quantum attack.
⊕ Note Kyber is a KEM — it slots directly into the KEM/DEM hybrid framework, keeping AES as the DEM.
Intuition
⊕ Even before a quantum computer exists, an adversary can RECORD today's encrypted traffic and store it. If the key exchange used RSA or ECDH, a future quantum computer decrypts the archive.
⊕ So data needing long-term secrecy must move to post-quantum KEMs NOW — often a HYBRID of a classical KEM and ML-KEM, so it's safe even if one is later broken.
Ask yourself: which kind of data is most at risk from harvest-now-decrypt-later? (Anything that stays sensitive for years — state secrets, health records — not an ephemeral one-off.)
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'Quantum computers break crypto, so AES is just as doomed as RSA — symmetric and asymmetric fall together.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: Shor's algorithm breaks RSA/ECC outright (efficient factoring / discrete log).
A student: how does the quantum threat differ for symmetric vs public-key crypto?
Why: Shor's algorithm breaks RSA/ECC outright (efficient factoring / discrete log). AES faces only Grover, a quadratic speedup — annoying, not fatal.
Trap
A student: 'Quantum computers break crypto, so AES is just as doomed as RSA — symmetric and asymmetric fall together.'
Treat AES and RSA as equally broken by quantum computers
Why: Wrong. Shor's algorithm breaks RSA/ECC outright (efficient factoring / discrete log). AES faces only Grover, a quadratic speedup — annoying, not fatal.
A student: how does the quantum threat differ for symmetric vs public-key crypto?
Shor breaks RSA/ECC; Grover only halves AES strength, fixed by doubling the key
Why: ⊕: public-key crypto needs new lattice-based schemes (ML-KEM/ML-DSA); symmetric crypto just moves to AES-256 and longer hashes.
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.
Constraint
Discussion prompt
Run The hybrid-encryption playbook with this step confiscated:
Use four keys, not one (§11.6, callback L24): separate enc and MAC keys, one pair per direction.
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 hybrid-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
Why do real systems use HYBRID encryption instead of directly RSA-encrypting the whole 50 MB file?
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: §11.6: public-key encryption is orders of magnitude slower than symmetric crypto — one 2048-bit RSA operation raises a 2048-bit number to a 2048-bit power mod a 2048-bit modulus, and doing that across 50 MB is infeasible. Plain schemes are also unsafe on meaningful data (deterministic RSA leaks repeats; simplified El Gamal is malleable, m→2m). Hybrid encryption fixes both: generate random session keys, encrypt the file with fast symmetric crypto (AES + HMAC), and use ONE public-key operation to wrap the random session key under Bob's public key. This is exactly how TLS and PGP work.
Check
Alice has Bob's authentic 2048-bit RSA public key and wants to send him a 50 MB encrypted file. Think through the right construction before choosing.
Check your understanding
Why do real systems use HYBRID encryption instead of directly RSA-encrypting the whole 50 MB file?
Answer: A
Why: §11.6: public-key encryption is orders of magnitude slower than symmetric crypto — one 2048-bit RSA operation raises a 2048-bit number to a 2048-bit power mod a 2048-bit modulus, and doing that across 50 MB is infeasible. Plain schemes are also unsafe on meaningful data (deterministic RSA leaks repeats; simplified El Gamal is malleable, m→2m). Hybrid encryption fixes both: generate random session keys, encrypt the file with fast symmetric crypto (AES + HMAC), and use ONE public-key operation to wrap the random session key under Bob's public key. This is exactly how TLS and PGP work.
Concept
Concept
Concept
Connect it up
Draw it
One page, no notation unless you need it: draw how these connect — The Public-Key Distribution Problem · Why Public-Key Crypto Is Slow · Hybrid Encryption & Session Keys · KEM/DEM & the Post-Quantum Future. Put an arrow wherever one of them is what makes another possible, and label the arrow with why.
Recap
You can now state the public-key distribution problem and trace the Attila key-substitution attack, explain why public-key crypto is too slow and unsafe to encrypt data directly, build hybrid encryption by wrapping random session keys and encrypting the body symmetrically, justify the four-key setup, and describe KEM/DEM and the Shor-vs-Grover post-quantum picture.
| Idea | § | The one-line version |
|---|---|---|
| Distribution problem | 11.5 | Alice needs Bob's AUTHENTIC key; needs integrity, not secrecy |
| Attila attack | 11.5 | Broadcast lets an active attacker swap in his own key (MITM) |
| Too slow | 11.6 | 2048-bit RSA per block; thousands× slower than AES |
| Unsafe on data | 11.6 | Deterministic RSA leaks repeats; El Gamal is malleable (m→2m) |
| Hybrid encryption | 11.6 | Wrap random session keys under PK_B; AES + HMAC the body |
| Four keys | 11.6 | Separate enc/MAC, one pair per direction (callback L24) |
| ⊕ KEM/DEM | supp. | KEM wraps the secret + DEM encrypts the data = hybrid |
| ⊕ Post-quantum | supp. | Shor breaks RSA/ECC; AES only needs longer keys vs Grover |
Want this taught 1-on-1? Alexander tutors Computer Security — $55/session, free consultation.