Chapter 15 of Trappe & Washington: the intruder-in-the-middle attack, illustrated by the book's two-grandmasters story, and the protocols built to prevent it. Key pre-distribution and its quadratic cost, the Blom scheme with its exact collusion threshold, authenticated key agreement, Kerberos through Cliff, Trent, Grant and Serge, public key infrastructure and X.509 chains of trust, PGP's web of trust, the SSL and TLS handshake and record protocols, and the Secure Electronic Transaction dual signature.
Subject: Cryptography · 60 slides · diagram-first lesson
Open the interactive version of this deck
Title
Cryptography · Chapter 15
Assembling the primitives: intruders in the middle, key distribution, Kerberos, certificates, PGP and TLS
Objectives
Fourteen chapters of components. This chapter builds systems from them — and Chapter 14 is the frame to read it with, because almost every technicality below exists to stop one attack.
Figure (svg): Three trust models: a hierarchy with certificate authorities, a web of peer endorsements, and a single trusted server.
Warm-up
Diffie-Hellman gives a shared key. RSA gives confidentiality to a public key. Signatures prove a private key was used.
Discussion prompt
What do all three quietly assume, and why can no amount of mathematics supply it?
Hint: Each one is about a key. Ask whose.
Answer:
All three assume you know whose key you have. Diffie-Hellman gives a key shared with somebody; RSA encrypts to whoever holds the matching private key; a signature proves a private key was used.
Mathematics cannot supply the binding, because a public key is just a number. Nothing about it says 'Bob'. The association between a key and a person is a fact about the world, and facts about the world are not derivable.
So every protocol in this chapter needs an anchor — something trusted before the protocol starts. A pre-shared key, a trusted server, a root certificate in your browser, or a friend whose key you verified in person.
And that is the honest summary of the whole chapter: no protocol creates trust from nothing. Each one relocates the problem to somewhere it is easier to solve — from n² pairs to one server, or from every website to a few dozen roots.
Figure (svg): Three trust models: a hierarchy with certificate authorities, a web of peer endorsements, and a single trusted server.
Section
Section 15.1 · pp. 290-293
Concept
The book's illustration is the best one available. Eve, who has recently learned the difference between a knight and a rook, claims she can play two chess grandmasters simultaneously and either win one game or draw both.
She waits for the first grandmaster to move, then plays that move against the second. When the second responds, she plays that against the first. She cannot lose both games — and she has no chess ability at all.
The same strategy works against cryptographic protocols. Against Diffie-Hellman: Eve intercepts α^x from Alice and sends Bob α^e; intercepts α^y from Bob and sends Alice α^e. Both ends complete successfully, sharing keys with Eve rather than with each other.
She solved no hard problem. She was on the path, and nothing in the protocol bound a value to a name. Many of the technicalities of the algorithms in this chapter are caused by efforts to thwart this attack.
Figure (svg): Eve relaying moves between two grandmasters, guaranteeing she does not lose both games.
Concept
The book opens with the other authentication failure, and it is the one people meet daily. You receive an email asking you to visit a website and update your account information. How can you be sure the site is legitimate?
An impostor sets up a page that looks correct, records what you type, and forwards it on. No cryptography is attacked; a human is.
The standard solution is certificates and a trusted authority, which Section 15.5 covers. But notice what the certificate actually establishes: that this key belongs to the domain named in it. Whether that domain is the one you meant is a question the certificate cannot answer, and the reason paypaI.com with a capital I gets a perfectly valid certificate.
So authentication in this chapter is always relative to a name, and choosing the right name remains the user's problem. That gap has never been closed and probably cannot be.
Figure (svg): The intruder-in-the-middle attack on Diffie-Hellman: Eve runs one exchange with each party and relays between them.
Socratic
Eve breaks Diffie-Hellman without computing a discrete logarithm.
Discussion prompt
Explain what she does attack, and what class of adversary this puts her in.
Hint: Chapter 1's attack models drew a line she has just crossed.
Answer:
**She attacks the binding, not the mathematics.** The protocol produces a shared key correctly; what it never establishes is who the other endpoint is. Eve substitutes her own values and both ends complete a perfectly correct exchange with her.
**This makes her an active adversary**, not a passive one. Chapter 1's four attack models distinguish an eavesdropper from someone who can inject and modify, and Diffie-Hellman is secure against the first and provides nothing against the second.
And an active position is not exotic. A hostile Wi-Fi access point, a compromised router, an ISP, a state-level tap — all are on the path by construction. Assuming a passive adversary is assuming the easier half of reality.
The fix must come from outside the key exchange, because nothing inside it can distinguish Eve's α^e from Bob's α^y. Something already trusted must vouch for the value — which is why the rest of this chapter is about where that trust comes from.
The general principle: a protocol's security claim is scoped to an adversary. 'Secure' without a named adversary is not a claim, and passive-only security is the most common thing people over-read.
Section
Section 15.2 · pp. 293-299
Concept
A cryptographic algorithm is only as strong as the security of its keys. If Alice and Bob cannot meet, can they still agree a key without compromising future communication?
The simplest answer is pre-distribution: a trusted authority, Trent, generates a key for every pair of users and delivers them in advance over secure channels.
\[ \binom{n}{2} = \frac{n(n-1)}{2} \text{ keys} \]
And the cost is quadratic. With n users Trent must generate and send n(n−1)/2 keys, and each user stores n−1 of them. At n = 1000 that is 499 500 keys created, distributed and protected — and adding one user means 1000 new key deliveries.
Public key cryptography solves this, and the book notes the catch: even the best public key systems are computationally slow compared with symmetric ones. A central server talking to many clients in short intervals sometimes needs something faster — which is what the next two schemes are for.
Figure (svg): The quadratic growth of pairwise keys against the linear growth of alternatives.
Concept
Blom's scheme reduces what Trent must send from n(n−1)/2 keys to n small pieces of data, while still letting any pair derive a shared key with no further communication.
Alice computes her key with Bob as K_AB = a_A + b_A·r_B. Bob computes K_BA = a_B + b_B·r_A. Both come out equal, because both expand to a + b(r_A + r_B) + c·r_A·r_B — a symmetric expression in the two users.
Storage is now linear, and any pair can talk immediately. The price is a security limit, and it is precise: the scheme is secure against a single adversary, and two users who conspire can recover a, b and c and then compute everyone's keys. For each k there are Blom schemes secure against k conspirators and broken by k+1.
Figure (svg): The Blom key pre-distribution scheme: Trent gives each user a personal linear function, and any two users evaluate each other's.
Worked example
The symmetry is the whole scheme, and it is one substitution.
Alice holds a_A = a + b·r_A and b_A = b + c·r_A
Why: Two numbers, delivered once by Trent.
She computes K_AB = a_A + b_A·r_B = (a + b·r_A) + (b + c·r_A)·r_B
Why: Substituting her own values and Bob's public r_B.
Expanding: a + b·r_A + b·r_B + c·r_A·r_B
Why: Four terms.
Bob computes K_BA = a_B + b_B·r_A = (a + b·r_B) + (b + c·r_B)·r_A = a + b·r_B + b·r_A + c·r_A·r_B
Why: The same four terms.
Verify: the expression is symmetric in r_A and r_B, so the two agree
Why: Neither party learns a, b or c, and neither can compute a key for a pair they are not in. But two conspirators have four equations in the three unknowns a, b, c — enough to solve, which is exactly the stated security limit.
Figure (svg): The Blom key pre-distribution scheme: Trent gives each user a personal linear function, and any two users evaluate each other's.
Concept
Diffie-Hellman produces a key and authenticates nothing, which Section 15.1 showed is fatal. An authenticated key agreement protocol adds evidence of identity to the exchange.
The mechanisms are all variations on one idea: each party proves knowledge of something only they could know, bound to the exchange itself.
The essential requirement is that the authentication cover the exchanged values, not merely accompany them. A signature over a fixed identity string proves who is present and lets Eve substitute the key material anyway. The transcript must be bound in.
Figure (svg): The intruder-in-the-middle attack on Diffie-Hellman: Eve runs one exchange with each party and relays between them.
Section
Section 15.3 · pp. 299-303
Concept
Named for the three-headed dog guarding the entrance to Hades, and grown out of MIT's Project Athena — a campus-wide network of workstations where students needed to reach their files from anywhere, over a public and thoroughly observable network.
It is a symmetric protocol, which is the point: no public key operations, so it is fast enough for a server handling many clients. The participants are:
Cliff and Serge start with no shared key at all. Everything they end up sharing is manufactured by the two servers.
Figure (svg): Kerberos: the client authenticates once to Trent, receives a ticket for Grant, and uses that to obtain tickets for each server.
Worked example
Two stages, and the reason for the second is worth noticing.
Cliff tells Trent who he is. Trent replies with a session key and a ticket for Grant, encrypted under Cliff's long-term key
Why: Cliff's password derives that long-term key locally, so the password never travels. If Cliff is an impostor, he cannot decrypt the reply.
Cliff decrypts, recovering the session key and the ticket. The ticket is encrypted under Grant's key, so Cliff cannot read or alter it
Why: A ticket is a sealed message from one server to another, carried by the client.
Cliff sends the ticket to Grant along with an authenticator — a timestamp encrypted under the session key
Why: The ticket says who Cliff is; the authenticator proves he holds the session key now, which is what stops a captured ticket being replayed.
Grant issues a ticket for Serge, with a fresh Cliff-Serge session key
Why: Cliff repeats the pattern with Serge.
Verify: count what Trent did: one interaction, at login
Why: The two-server split is the design's point. Trent holds every user's long-term key and is contacted once; Grant handles the frequent traffic. It also means Cliff's password is used once per session rather than once per service.
Figure (svg): Kerberos: the client authenticates once to Trent, receives a ticket for Grant, and uses that to obtain tickets for each server.
Socratic
Kerberos is elegant, symmetric and fast. It also makes assumptions the rest of this chapter is designed to avoid.
Discussion prompt
Name three assumptions, and say what happens when each fails.
Hint: Consider the servers, the clocks, and the scope.
Answer:
Trent knows every user's long-term key. So compromising Trent compromises everyone, past and future — he is a single point of total failure, which is exactly what public key infrastructures were designed to avoid.
Clocks are synchronised. The authenticator is a timestamp, and replay protection depends on rejecting old ones. Clock skew beyond the acceptance window breaks authentication; a window too wide permits replay. In practice this makes Kerberos deployments sensitive to time service failures in a way that surprises operators.
Everyone is in one administrative domain. Trent must share a key with every participant, which works on a campus and does not work between organisations that have never met. Cross-realm Kerberos exists and is awkward for exactly this reason.
And a fourth, from Chapter 12: the long-term key is derived from a password, so it inherits a password's entropy. An attacker who captures a ticket encrypted under it can mount an offline dictionary attack.
Which is why the internet uses certificates instead. X.509 trades Kerberos's speed and simplicity for scale across domains and no single key-holding authority.
Section
Sections 15.4-15.5 · pp. 303-309
Concept
You reach Gigafirm's checkout page and are asked for a credit card number. The site assures you it is using public key encryption with Gigafirm's key. How do you know Eve has not substituted her key?
This is the impostor problem and the intruder-in-the-middle problem in one, and it is the question a public key infrastructure exists to answer. A PKI is everything needed to make 'this key belongs to that name' a checkable statement: authorities, certificates, formats, revocation and policies.
Note what it does not do. It cannot tell you that Gigafirm is honest, that the site is the one you meant, or that the key has not been stolen since it was certified. It establishes one binding — key to name — and everything else is a separate problem.
Figure (svg): An X.509 certificate chain: a root CA signs an intermediate, which signs the server's certificate.
Concept
The most popular certificate format, and its validity depends on a chain of trust.
The root is self-signed, which proves nothing. It is trusted because it was installed in your browser, and that installation is the anchor the entire system rests on. Every other link is a signature you can check.
Figure (svg): An X.509 certificate chain: a root CA signs an intermediate, which signs the server's certificate.
Anomaly
A root CA's certificate is signed with its own private key. Verifying that signature confirms only that the holder of the key signed it.
Predict first
So why is the root trusted?
Correct: Because it was installed in your browser or operating system — the trust comes from the distribution channel, not from cryptography
Which is where the real risk lives. A browser trusts a few hundred roots, and any one of them can issue a valid certificate for any domain. A compromised or coerced CA is a total break of the binding for everyone — as happened with DigiNotar in 2011, which issued fraudulent certificates for Google and was removed from every browser.
The mitigations are all about detection rather than prevention: Certificate Transparency logs every issued certificate so an unexpected one is visible, and certificate pinning lets a site declare which CAs may vouch for it.
The general shape: every trust system terminates in something trusted for non-cryptographic reasons, and that termination is where to look for the weakness.
Why: A self-signature carries no information: anyone can generate a key pair and sign their own certificate. The root is trusted because it arrived with software you already trusted, through a channel you already relied on. The cryptography verifies every link below the root; the root itself is a matter of policy and distribution.
Section
Section 15.6 · pp. 309-312
Concept
Developed by Phil Zimmerman in the late 1980s and early 1990s, and in deliberate contrast to X.509: a very decentralised system with no CA.
Each user has a certificate, and its trustworthiness is certified to various degrees by other users. If Alice knows Bob and can verify his certificate directly, she signs it with her key. Charles, who trusts Alice and has her key, can check her signature and thereby trust Bob's certificate.
But trusting a key and trusting a signer are different things. Charles trusts Bob's key; that does not mean he trusts certificates Bob signs. Bob could be gullible and sign everything he meets — his signatures would be valid and the certificates worthless.
So Alice keeps a keyring recording her trust in each person's signatures at four levels: no information, no trust, partial trust, complete trust. A certificate is accepted if signed by someone she trusts completely, or by a sufficient combination of partial trusts; otherwise PGP alerts her and she decides.
Figure (svg): PGP's web of trust: users sign each other's certificates, and trust is assembled from several partial endorsements.
Comparison
Two answers to the same question. Fill the blanks.
Comparison matrix
| X.509 | PGP | |
|---|---|---|
| Structure | a hierarchy with a few roots | a decentralised web with no authority |
| Who vouches | a commercial CA, for a fee | other users, from direct knowledge |
| Anchor of trust | roots shipped in your browser | keys you verified in person |
| Scales to strangers? | yes — that is the point | poorly — needs a path of acquaintances |
| Single point of failure | any CA can vouch for any name | none — but no universal coverage either |
The trade is centralisation against coverage. X.509 lets you verify a stranger and requires you to trust hundreds of companies; PGP requires no authority and only works among people connected by a chain of acquaintance.
Section
Section 15.7 · pp. 312-314
Concept
If you have ever paid for anything over the internet, your transaction was probably protected by SSL or its close relative TLS. Secure Sockets Layer was developed by Netscape for secure HTTP; version 1 appeared in 1994, version 3 in 1995. Transport Layer Security is a slight modification of SSL 3, released by the IETF in 1999.
They are designed for communications between computers with no previous knowledge of each other's capabilities, which shapes everything about the design.
The handshake performs authentication between the two computers and lets them agree on parameters — which cipher, which key exchange, which MAC. It is Chapter 1's hybrid pattern: everything expensive happens once, and the symmetric record protocol carries the volume.
Figure (svg): The TLS handshake establishing parameters and keys, then the record protocol carrying the bulk of the data.
Worked example
Four jobs, and each answers something from an earlier chapter.
Negotiate capabilities: which cipher suites, which versions, which extensions both sides support
Why: Two computers with no prior knowledge of each other. This is also where downgrade attacks live — Chapter 14's export ciphersuites, selected by an attacker who controls the negotiation.
Authenticate the server, by certificate
Why: This is the answer to Section 15.1. Without it, everything else is an exchange with somebody unspecified.
Agree a session key, by key transport or ephemeral Diffie-Hellman
Why: TLS 1.3 removed key transport entirely in favour of ephemeral DH, for the forward secrecy Chapter 10 described.
Derive the record protocol's keys from the agreed secret, through a key derivation function
Why: Chapter 12's point: a shared secret is not a key until it has been through a KDF.
Verify: and bind the whole transcript into the authentication
Why: The signature must cover what was negotiated, or an attacker modifies the capability list and the endpoints never notice. TLS 1.3's handshake signs the transcript for exactly this reason, and earlier versions' failure to do so completely is where several downgrade attacks came from.
Figure (svg): The TLS handshake establishing parameters and keys, then the record protocol carrying the bulk of the data.
Concept
SET was a protocol developed in the 1990s by Visa and Mastercard specifically for card payments, and its design goal was one SSL does not address.
With SSL, the merchant receives your card number — it must, in order to process the payment. SET's aim was that the merchant learns what you bought and not your card number, while the bank learns your card number and not what you bought.
The mechanism is a dual signature: the customer hashes the order information and the payment information separately, concatenates the two digests, and signs that. The merchant receives the order plus the hash of the payment; the bank receives the payment plus the hash of the order. Each can verify the same signature without seeing the other's half.
It was not adopted. It required software on the customer's machine and certificates for every cardholder, and SSL plus a trusted merchant was good enough for the market. The idea survives — dual signatures appear in privacy-preserving protocols — and the deployment failure is a reminder that a protocol competes on operational cost, not only on security.
Figure (svg): The dual signature: one signature covering two hashes, so each party verifies its own half without seeing the other.
Definition probe
Every protocol here terminates in something trusted for non-cryptographic reasons.
Sort into buckets
Sort each protocol by its anchor.
Notation
An X.509 certificate is a signed statement, and knowing which fields the signature covers is what makes it checkable.
Annotate
On: \( \text{Cert} = \bigl\langle \text{subject}, \; \text{public key}, \; \text{issuer}, \; \text{validity}, \; \text{extensions} \bigr\rangle, \; \text{Sig}_{CA} \)
The signature covers all of it, so any field an implementation ignores is a field an attacker can rely on being ignored.
Error analysis
From a client library's TLS verification routine.
Annotate
attacker.example verifies perfectly; matching the subject against the host being contacted is a separate step that libraries have repeatedly omitted.The signature verified. Four other things did not, and each has appeared in a CVE.
Explain it to yourself
A handshake negotiates a cipher suite, then the server signs to prove its identity.
Discussion prompt
Explain what goes wrong if the signature covers only the server's identity and the key exchange values, and not the negotiation.
Hint: Ask what an attacker on the path can modify without invalidating the signature.
Answer:
She modifies the capability list. The client advertises modern and legacy cipher suites; the attacker strips the modern ones. Both ends then negotiate the weakest option both 'support', and the signature over the key exchange still verifies.
This is a downgrade attack, and it is how FREAK and Logjam worked in 2015: connections were forced down to export-grade 512-bit keys that had been legally mandated twenty years earlier and never removed.
The fix is to sign the transcript — a hash of every handshake message exchanged so far. Then any modification to the negotiation changes the hash, and the signature fails.
And it generalises beyond TLS. Any protocol with a negotiation phase must bind the negotiation into the authentication, or the negotiation becomes the attack surface.
The underlying principle is Chapter 14's: an authentication mechanism covers exactly what it covers. Anything outside the signed region is unprotected, and attackers read protocol specifications looking for exactly that boundary.
Two truths and a lie
Two of these claim more than any certificate provides.
Eliminate the wrong options
Which statement is correct?
Survives elimination: a
Why: The assertion is narrow and it is the only thing the mathematics supports. Everything users want a certificate to mean — that the site is legitimate, that the company is real, that their data is safe — is an inference they add. Being precise about the scope is what makes the failure modes predictable: a valid certificate for a phishing domain is not a failure of the system, it is the system working exactly as specified.
Ranking
Every trust system has components whose failure has different blast radii.
Put in order
Why: One server's key affects that server's traffic — serious, contained, and fixed by revocation. A ticket-granting server compromises one organisation's whole network, since it can mint tickets for any service. A CA's key allows valid certificates for any domain on the internet, which is what made DigiNotar's 2011 breach so severe. And the root store update mechanism is worse still: it decides which CAs are trusted at all, so compromising it inserts a new authority everywhere. The pattern is that each level up multiplies the number of parties affected.
Real world
The X.509 model's central risk is that any CA can vouch for any name. In 2011 that became concrete.
Discussion prompt
Describe the DigiNotar incident and the responses it produced.
Hint: One Dutch CA, certificates for Google, and a fast institutional reaction.
Answer:
DigiNotar, a Dutch certificate authority, was breached in 2011 and the attacker issued fraudulent certificates for major domains including Google's. Those certificates were cryptographically valid and would have been accepted by every browser in the world.
They were used, apparently to intercept traffic for large numbers of users in Iran — a working intruder-in-the-middle attack at national scale, made possible by one company's compromise.
The response was to remove DigiNotar from every browser's root store, which invalidated every certificate it had ever issued and effectively destroyed the company within months.
And it drove two structural changes. Certificate Transparency requires every issued certificate to be logged publicly, so a domain owner can detect an unexpected certificate for their name. And browsers began pinning certain high-value domains to specific CAs.
The lesson about the model: trust in X.509 is the union of trust in every root, not the intersection. Adding a CA cannot make the system safer, and a browser trusting three hundred roots is trusting the weakest of three hundred organisations.
Discrimination
The protocols in this chapter are assemblies, and each piece answers one thing.
Sort into buckets
Sort each mechanism.
Faded example
Fill the blanks and you have the recipe every protocol in this chapter follows.
Fill in the blanks
Diffie-Hellman alone gives a key shared with somebody. To fix it, each party must prove knowledge of a secret bound to something the other already trusts — a certificate, a pre-shared key or a password. The proof must cover the exchanged values, not merely accompany it, or an attacker substitutes the key material and the proof still verifies. And the trust must terminate in an anchor obtained outside the protocol.
Why: Three requirements, and protocols fail on each of them: on the first by omitting authentication entirely, on the second by signing an identity rather than a transcript, and on the third by trusting an anchor obtained over the same untrusted channel. The third is the subtlest — downloading a root certificate over plain HTTP defeats the whole chain, however well the signatures verify.
Cost model
TLS's split into two components is Chapter 1's hybrid argument made concrete.
Annotate
On: \( \text{handshake: a few public key ops} \quad \text{record: a symmetric cipher and a MAC per record} \)
The pattern from Chapter 1, one last time: expensive primitive once on something small, cheap primitive for the volume.
Commit first
A server uses TLS 1.3, a certificate from a public CA, AES-GCM and ephemeral Diffie-Hellman.
Predict first
What is the realistic failure?
Correct: Certificate validation on the client — chain, hostname, expiry or revocation
A close second is the trust anchor itself: a device shipping with a corporate interception CA installed, or an application bundling an outdated root store.
And the general point this chapter closes on: the protocol's security is a chain of many links, of which the cryptographic ones have been reviewed for decades and the validation logic was written to make a test pass.
Why: Everything on the server side here is current and sound. The failures appear on the client: libraries that verify a signature without walking the chain, applications that skip hostname matching, code that accepts expired certificates for compatibility, and revocation checks that fail open. These are the most frequently reported TLS vulnerabilities year after year, and none of them involves the cryptography.
Constraint
Three deployments: a university's internal services, a public e-commerce site, and encrypted email between activists.
Discussion prompt
Choose an approach for each and justify it against the setting's constraints.
Hint: The deciding question each time is where trust can be anchored.
Answer:
University internal services: Kerberos. One administrative domain, so a central authority can share a key with everyone. Symmetric operations are fast enough for a server handling thousands of logins, and single sign-on falls out of the ticket structure. This is the setting it was built for, at MIT.
Public e-commerce: TLS with X.509. The requirement is verifying strangers at scale, which only a hierarchy achieves — no pre-shared secret is possible with a customer who arrived a second ago. Accept the CA risk and mitigate it with Certificate Transparency.
Activist email: PGP, or a modern equivalent. No authority can be trusted, possibly including the state that licenses CAs, so trust must come from in-person verification. The web of trust scales badly and that is acceptable when the group is small and the threat model excludes trusting institutions.
And the general rule the three illustrate: the trust model follows from who can be trusted in advance, and the cryptography follows from the trust model. Choosing the algorithm first is choosing the least consequential thing first.
Note also that all three use the same primitives. The difference is entirely in where the anchor sits.
Figure (svg): Three trust models: a hierarchy with certificate authorities, a web of peer endorsements, and a single trusted server.
Edge cases
Blom's scheme is secure against one adversary and broken by two. That precision is unusual.
Discussion prompt
Show why two suffice, and say what the general k-secure version costs.
Hint: Count the equations each user's data provides against the number of unknowns.
Answer:
Each user's data is two linear equations in a, b, c. Alice knows a_A = a + b·r_A and b_A = b + c·r_A, with r_A public — so she has two equations in three unknowns and cannot solve.
Two users have four equations in three unknowns, which over-determines the system. Alice and Bob together solve for a, b and c, and can then compute every pair's key in the entire network.
The general scheme uses a symmetric polynomial of degree k rather than the degree-1 form here. Then each user's data gives k+1 equations, the unknowns number (k+1)(k+2)/2, and k conspirators are still short while k+1 succeed.
The cost is storage: each user stores k+1 coefficients instead of 2, so security against k conspirators costs storage linear in k. Compare pairwise pre-distribution, where full security costs storage linear in n — so Blom is a genuine improvement whenever k is much smaller than n.
And the design lesson: a scheme with a stated collusion threshold is far more useful than one whose security is 'we hope'. Knowing exactly where it breaks lets you size k against the deployment.
Explain it
Someone asks what the padlock in their browser actually means.
Discussion prompt
Explain it accurately, including what it does not mean, without using the word 'cryptography'.
Hint: An analogy about identity documents works well, and its limits are the same limits.
Answer:
The analogy: the site showed your browser something like an identity document, issued by a company your browser was already set up to believe. The document says 'this key belongs to bank.example', and your browser checked the issuer's mark on it.
What it means: your connection really is to whoever owns the name in the address bar, and nobody in between can read or alter it.
What it does not mean: that the company is honest, that the site is the one you intended, or that your data is safe once it arrives. A fraudulent site can get a perfectly valid document for its own name — and often does, because it is free and automatic.
The practical advice that follows: the padlock tells you the connection is private, and the address tells you who you are talking to. Reading the address is the part no technology does for you.
And the honest caveat: your browser trusts a few hundred issuers, and any of them could issue a document for any name. It has happened, and the response was to remove the issuer entirely.
Counterexample
A protocol has each party sign a fixed string containing their name, and send it alongside their Diffie-Hellman value.
Discussion prompt
Show that this does not prevent the intruder-in-the-middle attack.
Hint: Ask what the signature actually covers.
Answer:
Eve forwards the signatures unchanged. They are valid signatures over Alice's and Bob's names, and Eve does not need to forge either — she simply passes them along.
And she substitutes the Diffie-Hellman values, which the signatures do not cover. Alice receives Bob's genuine signature together with Eve's α^e, verifies the signature, and concludes she is talking to Bob.
So both ends authenticate correctly and share keys with Eve. The signature proved who was present; it did not prove which key material they sent.
The fix is to sign the exchanged values, or better, the whole transcript — then substituting α^e invalidates the signature and the attack fails.
The general rule, and it is the one this chapter turns on: an authentication mechanism protects exactly what it covers. Anything alongside the signed region is unprotected, and an attacker reads the specification looking for that boundary.
Figure (svg): The intruder-in-the-middle attack on Diffie-Hellman: Eve runs one exchange with each party and relays between them.
Picture it
Every protocol here answers the same question — where does the first trust come from — and the three answers have different failure modes.
Figure (svg): Three trust models: a hierarchy with certificate authorities, a web of peer endorsements, and a single trusted server.
None of the three is better. A hierarchy scales to strangers and concentrates risk; a web needs no authority and cannot reach one; a central server is fast and is a single point of total compromise.
Matching
Five attacks from this chapter and the last, each with a specific defence.
Match the pairs
Why: Five defences, and only the fourth is cryptographic in the ordinary sense. The others are structural: bind values to identities, prove freshness, cover the negotiation, and make misbehaviour detectable. That distribution is why protocol design is a separate discipline from primitive design, and why this chapter comes after fourteen chapters of primitives rather than before.
Estimation
Every root in the store can issue a valid certificate for any domain on the internet.
Predict first
Roughly how many certificate authorities does a typical browser trust?
Correct: One to two hundred
Each root may also have delegated to registration authorities and intermediates, so the number of keys capable of issuing a trusted certificate is larger still.
The practical mitigation has been detection rather than prevention: log every issuance publicly so a domain owner sees an unexpected certificate for their name, and remove authorities that misbehave — which is what happened to DigiNotar.
Why: Typically a hundred to two hundred root certificates, from organisations in many jurisdictions. Trust in X.509 is the union of trust in all of them, not the intersection — so the system's strength is that of its weakest member, and adding a CA can only reduce it. This is the structural criticism of the model, and it is why Certificate Transparency and pinning exist.
Figure (svg): An X.509 certificate chain: a root CA signs an intermediate, which signs the server's certificate.
Socratic
Trent authenticates Cliff, and Grant issues tickets for individual services. One server could do both.
Discussion prompt
What does the split buy, and what would be lost by merging them?
Hint: Count how often each server is contacted, and what each one holds.
Answer:
Trent holds every user's long-term key, derived from their password. That makes him the most sensitive component in the system, and the split means he is contacted once per session rather than once per service access.
Grant handles the frequent traffic and holds only session keys and service keys — no passwords. Compromising Grant is serious and bounded; compromising Trent is total.
And the user experience follows from it. Cliff's password is used once, at login, to decrypt Trent's reply. Every subsequent service access uses the ticket-granting ticket, so the password is not needed again — which is single sign-on, falling straight out of the structure.
Merging them would mean contacting the password-holding server on every print job and every mail check, multiplying both its exposure and its load.
The general design principle: separate the component holding long-term secrets from the component handling frequent requests. It appears again in PKI, where the root CA is kept offline and intermediates do the daily issuing — the same reasoning, a different protocol.
Error analysis
From an internal design document for a fleet of services.
Annotate
Four decisions, and each one takes a solved problem from this chapter and reintroduces it.
Trade off
Two anchors, two sets of consequences. Fill the blanks.
Comparison matrix
| Central server | Certificate hierarchy | |
|---|---|---|
| Works between strangers? | no — one administrative domain | yes — that is its purpose |
| Speed | symmetric, very fast | public key operations per handshake |
| Compromise of the anchor | every user's long-term key | any name can be vouched for by that CA |
| Number of parties trusted | one | one to two hundred roots |
| Detection of misbehaviour | internal audit | Certificate Transparency logs |
The fourth row is the uncomfortable one: a hierarchy scales by asking you to trust more parties, so the security of the whole is that of the least careful of them.
Ranking
The TLS handshake does four things. Rank by the severity of omitting each.
Put in order
Why: Omitting negotiation means a fixed cipher suite — inflexible, and survivable. Omitting the KDF means using a raw shared secret as a key, which has exploitable structure but is not immediately fatal. Omitting key agreement leaves nothing to encrypt with. And omitting authentication means the whole exchange happens with an unspecified party, so everything else is performed correctly and pointlessly. The ordering is by how completely the omission voids the rest.
Explain it to yourself
A self-signed certificate proves nothing about identity, and root CAs use them.
Discussion prompt
Explain what work a self-signature actually does, and when a self-signed certificate is appropriate.
Hint: It proves something narrow but not nothing.
Answer:
It proves the holder possesses the private key matching the public key in the certificate. That is a real assertion — it stops someone publishing a certificate for a key they do not control.
And it binds the fields together. The subject, validity period and extensions are all covered by the signature, so nobody can take a legitimate certificate and alter its contents.
What it cannot do is establish the name, because the assertion and the assertor are the same party. That is why a root is trusted through its distribution channel rather than through its signature.
When it is appropriate: whenever the verifier obtains the certificate through a channel it already trusts. A root shipped with the browser; an internal service whose certificate is baked into the client at build time; a pinned certificate in a mobile application. In all three the anchor is the delivery, and the self-signature does exactly the work it can do.
When it is not: for a public web server, where the visitor has no prior channel — which is why browsers warn so aggressively about them there. The warning is not that the cryptography is weak; it is that the anchor is missing.
Missing information
The phrase appears in every security questionnaire.
Discussion prompt
List what remains undetermined, in the order you would ask.
Hint: Most of the questions are about the client, not the server.
Answer:
Which version, and are old ones disabled? TLS 1.0 and 1.1 carry known problems, and leaving them enabled invites a downgrade.
Does the client validate certificates fully? Chain to a trusted root, hostname match, expiry, permitted-to-sign constraints, revocation. Every one has been omitted in shipping code, and a server cannot enforce any of them.
Is the trust store appropriate? A bundled outdated root store, or a corporate interception CA installed on the device, changes what 'trusted' means.
Is there forward secrecy? Ephemeral key agreement, or key transport that lets recorded traffic be decrypted later.
Is certificate pinning used where it should be? For a mobile application talking to its own backend, pinning removes the dependence on hundreds of CAs entirely.
And what happens on failure? A client that falls back to plaintext, or shows a dismissible warning, has an authentication mechanism the user can be persuaded to bypass.
Six questions, five of them about the client — which is where TLS deployments actually fail.
Commit first
Four systems, each depending on a different trust anchor for a ten-year deployment.
Predict first
Which dependency is riskiest?
Correct: A single certificate authority chosen by the vendor and pinned
The lesson is that pinning is a genuine security improvement and an availability risk, and the usual answer is to pin to a set of keys with a documented rotation path rather than to a single certificate.
It also illustrates the chapter's recurring point: over a long deployment the question is not only 'is this secure' but 'what is the plan when this anchor goes away'.
Why: Pinning to one CA removes the benefit of the hierarchy — you no longer depend on the weakest of hundreds — and replaces it with total dependence on one company over ten years. If that CA is compromised, ceases trading, or is removed from root stores, every deployed device fails and there is no fallback. The other three all have recovery routes: OS root stores are updated, an in-person key can be re-verified, and an internal server can be rebuilt.
Pattern
Nine protocols in this chapter, and the same five questions open all of them.
Chapter 14 supplied the fault categories; this chapter supplies the questions. Between them they cover every protocol failure in the book — and the last question is the one designs most often leave unanswered.
Figure (svg): Three trust models: a hierarchy with certificate authorities, a web of peer endorsements, and a single trusted server.
Trap
The trap. The TLS handshake completed, the certificate chain verified against a trusted root, and the browser shows a padlock. Therefore the connection is secure and the site can be trusted with a credit card number.
This is what the padlock is universally understood to mean, and it is what most user interfaces have encouraged.
Why it fails. The certificate asserts one thing: this public key belongs to the name in the certificate. It says nothing about whether that name is the one you meant, whether its operator is honest, or whether the private key has since been stolen.
A phishing site gets a valid certificate for its own domain, free and automatically. The padlock appears, the chain verifies, and the connection is genuinely private — to a criminal. The system worked exactly as designed.
And the verification itself is a chain of checks, most of which are outside the signature: hostname matching, expiry, chain length, whether an intermediate was permitted to sign, revocation status. Every one has been omitted in shipping code, and each omission makes a valid-looking connection insecure.
Then there is the anchor. Your browser trusts hundreds of CAs, any of which can vouch for any name. DigiNotar's 2011 compromise produced valid certificates for Google, and the only remedy was removing the CA entirely.
The accurate statement is narrow: the connection is private, to whoever owns the name shown in the address bar, as vouched for by one of several hundred organisations. Everything users infer beyond that, they supply themselves.
Check
Work it out before you click.
Check your understanding
Eve mounts an intruder-in-the-middle attack on Diffie-Hellman. What did she have to break?
Answer: B
Why: Eve runs one correct exchange with each party using her own exponent, and relays traffic between them. She solves no hard problem and needs no computation beyond the protocol's own. What she exploits is the absence of authentication, which is why the fix must come from outside the key exchange.
Check
Count equations against unknowns.
Check your understanding
In the basic Blom scheme with secrets a, b, c, how many users must conspire to recover them?
Answer: B
Why: Each user's data gives two linear equations in the three unknowns, so one user is short and two have four equations — over-determined and solvable. Having a, b and c, the conspirators compute every pair's key in the network. The general degree-k version is secure against k conspirators and broken by k+1, which is an unusually precise security statement.
Check
In Kerberos, Cliff carries a ticket he cannot read.
Check your understanding
Why can Cliff not forge or alter the ticket he is carrying?
Answer: B
Why: Kerberos is entirely symmetric — there are no signatures. The ticket is encrypted under a key shared between the issuing server and the destination server, so Cliff can carry it and cannot read or modify it. He also sends an authenticator encrypted under the session key, which proves he holds that key now and stops a captured ticket being replayed.
Connect it up
Nine protocols, and the useful way to organise them is by where trust starts.
Draw it
Draw four columns — pre-shared key, central server, certificate hierarchy, personal verification — and place Blom, Kerberos, X.509/TLS and PGP in them. For each, note what a compromise of the anchor costs and how far it spreads. Then write the intruder-in-the-middle attack in three lines and, beside it, how each of the four models defeats it. Finish with the five questions from the pattern slide.
The blast-radius column is the one to keep: it is what distinguishes an incident from a catastrophe, and it is decided by the trust model rather than by the cryptography.
Exit ticket
One question about what this chapter adds to the previous fourteen.
Predict first
Why can no cryptographic protocol establish trust from nothing?
Correct: Because a public key is a number and nothing about it identifies its owner — the binding is a fact about the world, and every protocol must obtain it from somewhere outside itself
Why: Mathematics can prove that whoever holds a private key produced a value. It cannot prove who that is, because the association between a key and a person is not a mathematical fact. So every protocol here begins from an anchor obtained outside it — a pre-shared key, a trusted server, a root certificate installed with the browser, or a fingerprint verified in person. Recognising that the anchor exists, and where it is, is the first step in reading any protocol.
Recap
Nine protocols, and one attack that shapes all of them.
Chapter 16 next. Digital cash, where the requirements go beyond anything so far: a coin must be unforgeable, spendable once, and anonymous — and the protocols use the blind signatures of Chapter 13 to achieve all three at once.
Figure (svg): Three trust models: a hierarchy with certificate authorities, a web of peer endorsements, and a single trusted server.
Want this taught 1-on-1? Alexander tutors Cryptography — $55/session, free consultation.