Key distribution is the unglamorous half of public-key cryptography. The mathematics of encrypting email works only if the key you encrypt to actually belongs to your correspondent, and finding that key needs infrastructure. The story of PGP's keyserver infrastructure is worth knowing both as history and as a design lesson, because the ideas that replaced it are the ones securing modern encrypted communication.
The SKS network and its founding assumptions
For most of PGP's life, the backbone of key discovery was the SKS (Synchronizing Key Server) pool: a federation of volunteer-run servers speaking the HKP protocol, continuously reconciling their databases so that a key uploaded to one server propagated to all of them. Three properties defined the design. Anyone could upload any key. Keys carried third-party signatures, the raw material of the web of trust, and anyone could attach a signature to anyone's key. And nothing was ever deleted, since the reconciliation protocol was built to converge on the union of everything every server had seen.
Each property was principled. Open upload meant no gatekeeper. Open signatures were the web of trust's entire mechanism. Append-only reconciliation meant no server operator, and no government leaning on one, could quietly make a key disappear. The design assumed participants who wanted the system to work.
The 2019 certificate flooding attack
In June 2019, unknown attackers attached tens of thousands of junk third-party signatures to the public keys of two prominent OpenPGP community members, Robert J. Hansen and Daniel Kahn Gillmor. One poisoned certificate swelled to roughly 150,000 signatures, on the order of tens of megabytes for a single key.
The payload landed downstream. GnuPG, the software that would import these keys, choked on certificates that large: fetching a poisoned key could hang the client and leave keyrings in a state that broke routine operations. Anyone whose tooling automatically refreshed keys from the keyserver network could have their PGP setup degraded by an upload they never saw, performed by a stranger, against a third party's key.
The attack required no cryptographic break and no compromised server. Every step used the keyserver network exactly as designed: open upload, open signatures, permanent storage. The design was the vulnerability. The lesson the OpenPGP community drew in the attack's aftermath
The maintainers' own assessment was blunt: the SKS codebase, an academic proof of concept in OCaml with a reconciliation protocol that made filtering structurally difficult, was not realistically fixable. The pool never recovered. Over the following two years the SKS pool DNS was retired, and the era of the append-only global keyserver effectively ended.
What replaced it
Key discovery did not get one successor. It got several, each abandoning a different founding assumption.
| Mechanism | How it works | What it gave up |
|---|---|---|
| keys.openpgp.org | A verifying keyserver, launched in 2019 on new software. Identity information is published only after the email address confirms via a verification mail, third-party signatures are not distributed, and users can delete their data. | The web of trust (no third-party signatures) and federation (it is one operated service, not a pool). |
| WKD (Web Key Directory) | Your mail domain publishes your key at a well-known HTTPS path derived from your address. Clients fetch it directly from the domain itself. | Neutral third parties. The domain operator controls what key is served, which is exactly right when the domain is your provider and exactly wrong if the domain is hostile. |
| Autocrypt | Keys ride along in the headers of ordinary email, so capability is discovered in the course of corresponding. Covered in our Autocrypt post. | First-contact security: it is opportunistic by design, trading initial authentication for usability. |
| Key transparency | Providers publish key directories backed by append-only, auditable logs, so a directory that serves different keys to different people can be caught. Covered in our key transparency post. | Nothing significant yet except deployment effort, which is why it is where modern systems are converging. |
Every append-only, accept-anything public datastore is a standing offer to whoever shows up with the worst intentions. The SKS network held that offer open for twenty years before someone accepted it. Systems that survive treat write access, verification, and abuse handling as part of the security model, not as social assumptions.
What this means for encrypted email today
If you use PGP directly, the practical guidance is short. Publish your key where your correspondents' tools will actually look: keys.openpgp.org and, if your provider supports it, WKD. Do not point automated refresh at surviving legacy HKP servers, some of which still carry poisoned certificates. And treat any key fetched from any directory as unauthenticated until you have checked its fingerprint through a second channel, the discipline covered in our TOFU post.
The larger point is about what key discovery should look like when it is someone's job rather than a volunteer commons. The OpenPGP crypto refresh modernized the message format, but discovery was never going to be fixed by a format. It is fixed operationally: a provider that manages keys for its users, verifies addresses before publishing, serves keys over authenticated channels, and works toward transparency logs that make directory misbehavior detectable. That is the model encrypted email has been converging on since the phone book burned down, and it is the reason a key fetched today arrives with better authentication at first contact than one fetched in the SKS era, even though the cryptography is largely the same.