Your PGP Key on a Public Server: What Anyone Can Learn From It

Published 24 September 2026

Every PGP user is told the same thing: the public key is public, hand it out freely, there's nothing secret in it. That's true in the cryptographic sense. Your private key stays on your machine and nobody factors an elliptic curve because they found your public half. But "nothing secret" is not the same as "nothing interesting", and a key uploaded to a keyserver is one of the more revealing documents you can publish about yourself without realising it.

What's actually inside a public key

A public key packet is a structured file, not just a blob of key material. Parsing one with gpg --list-packets shows the layers:

• User IDs. Every name-and-email pair you've attached: "Jane Doe <jane@example.com>", plus old addresses you forgot you signed. All of them ship with the key, forever.
• Creation date. A timestamp accurate to the second. Combined with a work email, that's a join date. That's "Jane has been at this company since March 2021".
• Algorithm and size. RSA-2048 made in 2013 says something about how current your setup is, or isn't.
• Subkeys and their flags. Which subkey signs, which encrypts, when each was rotated. If you added a new encryption subkey after a laptop died, the key shows the scar.
• A photo, if you ever attached one. PGP supports image User IDs. People attach a photo when they generate the key, forget it, and upload the whole thing.
• Self-signatures and key flags. Expiry policy, preferred algorithms, whether the key is marked for certification only.

None of that breaks encryption. All of it is a structured dossier on your identity, your email history and your habits, published in a format designed to be copied forever.

What signatures add on top

Other people's signatures on your key are the more social leak. A colleague signs your key after verifying you at a conference; now the public record shows a cryptographic link between your identities, with a date. A key with twenty signatures from a company's employees maps that company's social graph, and the signing dates sketch out its conference calendar. Researchers have done exactly this: the Web of Trust has been used to study organisational structure, because that's literally what it records. If your threat model includes "employer shouldn't know I attend crypto meetups", the signature trail matters more than the User ID.

What the modern keyservers no longer do

The old SKS keyserver network shut down in 2021, killed by certificate flooding: attackers appended garbage signatures to targeted keys and synced them everywhere, making the keys unusable to fetch. Its successors behaved differently on purpose.

keys.openpgp.org only serves a User ID if you've verified that email address with them, so strangers fetching your key by fingerprint get the key material without your name and inbox. Mailvelope's key server verifies addresses at upload too. Proton publishes the public half of its users' keys through its own WKD-style lookup, attached to the address, but it doesn't accept third-party signatures at all. The verification-free firehose is mostly gone. That's privacy progress, with one cost covered below.

The double-edged part: third-party signatures

Those verification requirements killed a real feature. The Web of Trust's point was that someone who had verified you face to face could vouch for the key, and strangers could weigh the vouches. Modern servers strip or reject those signatures, so a fetched key carries less corroboration. You trade a decentralised identity system for a cleaner privacy posture. For nearly everyone that's the right trade, and the manual fingerprint check does the job signatures used to do. We've walked the practical side of that exchange in how to verify a key before you trust it.

How to see what you've already published

Two commands, run locally, tell you what strangers can pull:

gpg --list-packets yourkey.asc dumps every User ID, subkey and signature with dates.

Fetch your own key from keys.openpgp.org by fingerprint and diff it against your local copy. Anything present locally but absent remotely is a User ID the verifying server withheld. If a surprise appears, an email from 2012, a photo packet, you've found what the internet has been holding onto.

Publishing less

Cleanest option: skip keyservers entirely and serve your key from your own domain with the Web Key Directory. Mail clients fetch it automatically from https://yourdomain/.well-known/openpgpkey/..., no third party aggregates anything, and you control the copy. For most people with their own domain it's strictly better.

Otherwise, strip before you upload. Export, remove stale User IDs and the photo locally, and upload the pruned key. Two identities on one key is another common pattern, a personal address and a work address, and it's usually a mistake, because the key fuses them permanently. We broke down splitting and consolidating identities in multiple PGP keys for one identity.

And if a key carries history you truly want gone, remember the only real delete button: publish a revocation certificate, retire the key, and start fresh. A revoked key stops being fetched, though old copies in archives never disappear. That asymmetry is permanent. Publish like a librarian is watching, because eventually one is.

One last note on timing: if you're about to publish a key for the first time, do the pruning before the first upload rather than after. Every keyserver copy operation between the old and new version lives on in archives and mirrors, and the cleanup job is always harder than the initial discipline. Thirty seconds with gpg --edit-key before you paste anything saves a weekend of key surgery later.