I have been telling myself I will get serious about PGP for at least three years. Every six months I go through a flurry of generating keys, signing the keys of friends, and uploading to public keyservers. Every six months it then quietly lapses, and I find myself sending mail in plain text again, with the only encryption being the SSH-tunnelled SMTP submission on the way to my outbound mail server.
I am not the only person doing this. Almost nobody uses PGP for routine email, despite it having been freely available since 1991 and despite it being the only mechanism that actually solves the end-to-end mail encryption problem.
The reasons are interesting and they are mostly not technical.
What PGP is, briefly
PGP — Phil Zimmermann's Pretty Good Privacy — provides three things together: encryption of mail content so that only the intended recipient can read it; signing of mail content so that the recipient can verify it has not been altered; and a key distribution scheme — the web of trust — that lets you build confidence in someone's public key without a centralised authority.
The combination is, as far as I know, still the gold standard for email security. There are alternatives — S/MIME for instance — but PGP's web-of-trust model is more resistant to centralised compromise than the alternatives, and the cryptography is still solid.
Why nobody uses it
Three problems. Stack-ranked by how often they actually bite.
Key distribution is hard. To send encrypted mail to someone, you need their public key. To verify their signature, you need their public key. To trust their public key, you need at least one signature on it from someone you trust.
None of this happens automatically. You ask the person for their key, or look it up on a public keyserver, or download it from their website. Then you have to verify, out of band, that the key you received is the right one — which usually means a phone call to the key's owner so they can read out the fingerprint.
The key-fingerprint phone call is the friction that kills most adoption. It is a non-zero amount of effort, every time you want to start communicating securely with someone new. Most people will not do it. The few who will do it once will not do it again.
Software integration is poor. No mail client I use supports PGP natively. There are plugins, hooks, command-line wrappers. They mostly work. They mostly require attention each time you compose a message — "sign this? encrypt this? to whom?".
This is in stark contrast to other security mechanisms — TLS for HTTPS, for instance — which are essentially invisible to the user. The lock icon in the browser is the only feedback. Users do not need to think about whether they want HTTPS for any given visit; they get it.
For PGP to be similarly invisible, the mail client would need to: have your private key available; know the recipients' public keys (preferably automatically from previous correspondence); decide automatically whether to sign or encrypt based on policy; do all of this with no user thought required.
No mail client does this. Most do not even attempt it.
The web of trust is hard to bootstrap. The model assumes you have at least a few trusted contacts whose keys are signed by people whose keys are signed by yet more people. Once you have this seed, the web grows organically — you can verify keys for people two or three hops away.
The seed is the problem. You need to attend a key-signing party, or visit your contacts in person, to get your initial set of signatures. Without that initial seed, your key floats unverified, and other people's keys appear to you as untrusted.
Key-signing parties exist. They are mostly attended by people who are already in the trust web. New entrants struggle.
What I have actually been doing
My current state, which I am writing down for future-me to read:
- I have a PGP key. The fingerprint is on my web page.
- The key is on
pgp.netandkeys.pgp.net. - I have it signed by three people, all of whom I know personally, none of whom have many signatures themselves.
- I sign all the mail I send to other key-holders, with a procmail rule that does it automatically.
- I encrypt mail only when explicitly asked to.
The encryption-only-when-asked is the embarrassing part. It is the right tool for serious operational secrets, and I do not use it routinely because the friction is high enough that I do not bother.
This is a bad habit. The right habit, if I am being honest, is encrypt by default to anyone whose key I have, and let the rare cases where the recipient cannot decrypt fall back to plain text with a notice. I have not built the procmail rules to do this, partly out of laziness and partly out of worry about the edge cases.
A note on the alternatives
A few alternatives exist or are emerging.
S/MIME uses X.509 certificates instead of the web of trust. It has wider commercial backing and is integrated into Outlook and Netscape Communicator. The trust model — "believe a CA" — is structurally weaker than the web of trust but considerably easier to bootstrap. For corporate use it is, on balance, more deployable.
STARTTLS for SMTP encrypts the transport between mail servers, but not the message itself. The recipient, the sender, and any operator at either end can read the plain text. It is useful as a defence against passive snoopers on intermediate networks; it is no defence at all against any of the actors in the mail handling pipeline.
Neither solves the problem PGP solves.
What would have to change
For PGP to actually become widely used, three things would need to happen.
Mail clients would need to integrate it natively. Not as a plugin. Not as an after-the-fact wrapper. As a first-class feature, with sensible defaults, no UI for normal users beyond "is this message protected?" indicators.
Key distribution would need to be automated. When I exchange mail with a new correspondent, my client should fetch their key from a directory, present me with a fingerprint, and offer to remember it. Out-of-band fingerprint verification should be optional, not required, with an audit trail of any key changes.
The web of trust would need to be re-thought. The current model is too sparse for general use. Some kind of reputation system, or some integration with a directory of keys signed by major institutions, or some hybrid with X.509 — any of these would lower the bootstrap cost.
None of this is technically hard. All of it requires a lot of coordinated work across many software vendors and many users. The incentives, frankly, are weak — most users do not perceive their mail as needing this level of protection most of the time, even when, examined carefully, it does.
What I am going to actually do
For the rest of this year, I am going to try a small experiment. I will only sign every outgoing message — automatically, no thought required. I will not push encryption beyond where it is currently used. The signature alone is the smallest discipline I can sustain, and the data point I am most curious about is: do my correspondents ever notice or ask?
My guess is that none of them will. The signature will go unnoticed and unused. This is, in itself, a useful data point — it confirms that the bottleneck is not generating signatures but verifying them, which is to say, the bottleneck is on the receiving side.
More on this in six months.