Nothing in this section is new. It is the first place the chapter’s tools are assembled into a working system, and the assembly turns out to be nothing more than feeding one design into another.
Words you will meet
-
Session key session key Simple A symmetric key made up for one conversation and then thrown away. Precise A random symmetric key K_S chosen for a single session, used to encrypt the message body because symmetric encryption is far cheaper than public key encryption, and itself sent encrypted with the receiver's public key. introduced in ch. 8 — open in glossary — a random symmetric key K_S, made for one message and then discarded.
-
Package — the concatenation of the encrypted message and the encrypted key.
-
PGP (Pretty Good Privacy) Pretty Good Privacy Phil Zimmermann's 1991 e-mail encryption scheme, certifying keys through a web of trust rather than a CA. introduced in ch. 8 — Phil Zimmermann’s 1991 e-mail security software.
-
Web of trust — certifying keys by vouching for each other, with no authority.
-
Key-signing party — people meeting physically to exchange and certify public keys.
Why this matters
Security can be provided at any of the top four layers, and sections 8.5 to 8.8 do it once at each. Application here, transport in 8.6, network in 8.7, link in 8.8.
The obvious question is why more than one layer. Why not put it all at the network layer and be finished?
Two answers. Network-layer security cannot provide user-level security — a commerce site cannot rely on it to authenticate a customer buying goods. And it is far easier to deploy new services at higher layers, which is why application developers stopped waiting. PGP is the classic case: requiring only client and server application code, it became one of the first security technologies broadly used on the Internet.
Three systems, built separately
The book designs three e-mail systems in a row, and the order is the lesson.
Alice could simply encrypt the message with Bob's public key, and Bob decrypt it with his private key. That works — but public key encryption is inefficient, and e-mail messages are long.
Each panel adds one property. Watch the third: it does not invent anything, it feeds the output of one machine into the other.
Read all steps as text
- Confidentiality alone — the obvious way, and why it is too slow — Alice could simply encrypt the message with Bob's public key, and Bob decrypt it with his private key. That works — but public key encryption is inefficient, and e-mail messages are long.
- Confidentiality with a session key — Figure 8.19 — Alice picks a random symmetric session key K_S, encrypts the message with it, encrypts K_S with Bob's public key, concatenates the two into a package, and sends it. Bob recovers K_S with his private key, then the message with K_S.
- Authentication and integrity, with no confidentiality at all — Figure 8.20 — A different system. Alice hashes the message, signs the hash with her private key, and concatenates the signature with the UNENCRYPTED message. Bob applies Alice's public key to the signature and compares it with his own hash of the message.
- All three together — Figure 8.21 — Alice builds the signed package of Figure 8.20, then treats that whole package as if it were an ordinary message and runs it through Figure 8.19. Bob undoes Figure 8.19 first, then Figure 8.20.
The first provides confidentiality. Alice could encrypt the message with Bob’s public key directly, and that works — but public key encryption is inefficient, particularly for long messages, and e-mail messages are long.
So she uses a session key session key Simple A symmetric key made up for one conversation and then thrown away. Precise A random symmetric key K_S chosen for a single session, used to encrypt the message body because symmetric encryption is far cheaper than public key encryption, and itself sent encrypted with the receiver's public key. introduced in ch. 8 — open in glossary instead. Five steps:
- Select a random symmetric session key
K_S. - Encrypt the message m with
K_S. - Encrypt
K_Swith Bob’s public keyK⁺_B. - Concatenate the two into a package.
- Send the package to Bob’s e-mail address.
Bob uses his private key to recover K_S, then K_S to recover m.
In plain words
The expensive lock is used once, on the key to the cheap lock. The cheap lock does all the actual work.
That is the same three lines as section 8.2.2, and you will see them again in TLS (Transport Layer Security) Transport Layer Security Encryption, integrity and authentication added above TCP, in the application layer. introduced in ch. 2 and in IPsec (IP Security) IP Security The network-layer security suite, most often used in tunnel mode to build VPNs. introduced in ch. 8 . It is the standard shape of every real protocol in this chapter.
The second provides sender authentication and message integrity, and no confidentiality at all. The book suspends the confidentiality requirement deliberately — Alice and Bob, it says, want to share their feelings with everyone.
Alice hashes the message, signs the hash with her private key, and concatenates the signature with the unencrypted message. Bob applies Alice’s public key to the signature and compares the result with his own hash of the message. If they agree, the message came from Alice and is unaltered.
The third combines them, and invents nothing. Alice builds the signed package exactly as in the second system, then treats that whole package as if it were an ordinary message and runs it through the first system.
Bob undoes them in the reverse order.
| Figure 8.19session key | Figure 8.20hash and signature | Figure 8.21the two combined | |
|---|---|---|---|
| Confidentiality | |||
| Sender authentication | |||
| Message integrity | |||
| Is the message readable on the wire? | |||
| What the expensive public key operation runs on |
Cells marked ⓘ have a reason behind them — click to read it.
The book designs these separately on purpose. Notice that the second provides no confidentiality whatever, and is still useful. Click any cell.
Why the order is signature-then-encryption
Alice signs first and encrypts second, so the signature ends up inside the encrypted package.
Consider the alternative. If she encrypted first and signed the ciphertext, anyone watching the wire could see who signed it — the signature would be in the clear, and it identifies the sender. Signing on the inside means an eavesdropper learns neither the message nor who wrote it.
The book’s Figure 8.21 has this order, and the composition is what makes it free: the signed package is simply treated as a message.
PGP
Pretty Good Privacy, written by Phil Zimmermann in 1991, is essentially the design of Figure 8.21 as a piece of software.
| Job | Algorithm | Which part of the design |
|---|---|---|
Cells marked ⓘ have an explanation — click to read it.
The design is Figure 8.21. These are the algorithms plugged into it, and they vary by version.
When PGP is installed it creates a public key pair for the user. The public key can be posted on a web site or placed in a public key server. The private key is protected by a password, which must be entered every time it is accessed.
The user chooses per message: sign it, encrypt it, or both.
What a PGP message looks like
A signed message carries the plaintext, then a block of encoded data between
BEGIN PGP SIGNATURE and END PGP SIGNATURE. That encoded block is
K⁻_A(H(m)) — the digitally signed message digest, and nothing else. Bob needs
Alice’s public key to check it.
A secret message is a single encoded block between BEGIN PGP MESSAGE and
END PGP MESSAGE. The plaintext does not appear anywhere in it.
For both confidentiality and integrity, PGP puts a message of the second kind inside a message of the first. Both appear after the MIME header, so ordinary e-mail infrastructure carries them without knowing what they are.
Certification without an authority
Section 8.3.3 said public keys must be bound to identities by a certification authority. PGP does it completely differently.
PGP public keys are certified by a web of trust. Alice can certify any key-and-username pair herself, whenever she believes the pair really belong together. She can also declare that she trusts another user to vouch for further keys, so trust propagates outward from people she has checked personally.
Some users hold key-signing parties: they gather physically, exchange public keys, and certify each other’s keys by signing them with their private keys.
Two answers to the same question
Both models solve the problem the pizza prank exposed — how do you know whose public key you hold — and they answer it in opposite directions.
A certification authority is hierarchical. One organisation checks identities, and everyone trusts it because of what it is.
A web of trust is horizontal. There is no authority at all; you trust keys because you checked them yourself, or because someone you already trust checked them.
Neither removes the need to trust something. They differ in whom, and in whether that decision is yours to make.
The mental model
An e-mail security system is three separate mechanisms and one composition rule.
Session key for confidentiality, because public key encryption is too slow for a long message. Hash and signature for authentication and integrity, because the signature must be unique to Alice. And to get all three, sign first, then encrypt the signed package as though it were an ordinary message.
Every remaining protocol in this chapter is a rearrangement of those same parts.
Check yourself
Check yourself
0 of 7 answered1.Alice could encrypt her e-mail directly with Bob's public key. Why does the book use a session key instead?
2.In Figure 8.20, the message travels unencrypted. Why is that not a mistake?
3.predictTo get all three properties, what does Alice do that she has not done before?
4.Alice signs first and encrypts second, so the signature ends up inside the encrypted package. What would be lost by doing it the other way round?
5.Why is security provided at four different layers rather than only at the network layer?
6.What is in the encoded block of a PGP signed message, between BEGIN PGP SIGNATURE and END PGP SIGNATURE?
7.How does PGP's web of trust differ from a certification authority?
What to remember
-
The combined design invents nothing. The signed package of Figure 8.20 is fed into Figure 8.19 as if it were an ordinary message. That is why the order is sign first, encrypt second, which leaves the signature inside the encryption where an eavesdropper cannot see who wrote it.
-
Security lives at four layers because the network layer cannot do it all. It offers blanket coverage but no user-level authentication, and higher layers are far easier to deploy — which is exactly how PGP arrived before anything below it did.
-
PGP certifies keys with a web of trust, not an authority. You certify keys you have checked yourself, and delegate to people you already trust — the horizontal answer to the question section 8.3.3 answered hierarchically.