You've got someone's public PGP key. You're about to encrypt a message to it that only they should be able to read. But how do you know the key actually belongs to them?
This is the hardest problem in PGP, and it always has been. The encryption itself is mathematically sound. The key distribution and verification step is where the system has always been fragile. If you encrypt to the wrong key, you haven't sent a private message. You've sent a message that the wrong person can read, and the right person can't.
Here's how verification actually works in practice, from the quick check to the full web-of-trust model.
The fingerprint check
Every PGP key has a fingerprint, typically a 40-character hex string for older RSA keys or a shorter one for Ed25519. You can get it with gpg --fingerprint or by pasting the key into any PGP tool.
The fingerprint is a hash of the key material. Two different keys can't have the same fingerprint unless someone has broken SHA-1 (for v3 keys, which you shouldn't use) or SHA-2 (for v4 keys, which is what everyone uses now).
The standard verification procedure is: obtain the fingerprint over a channel you trust, then compare it to the fingerprint of the key you have. If they match, the key is genuine. If they don't, someone has substituted a different key.
The key phrase in that procedure is "over a channel you trust." If you get the fingerprint from the same email or website where you got the key, you have verified nothing. The attacker who swapped the key also swapped the fingerprint.
Practical options for a trusted channel:
- Meet in person and read fingerprints to each other. This is how PGP keysigning parties work. It sounds tedious, and it is, but it's the gold standard.
- Phone the person and read the fingerprint aloud. Their voice is a separate channel from their email.
- Check multiple independent sources. If their fingerprint is on their personal website, their GitHub profile, their Twitter bio, and a keyserver, and all four match, your confidence is much higher than any single source.
Key signatures: the web of trust
The web of trust is the system PGP uses to scale verification beyond people you can meet in person. The idea is simple: if someone you trust has verified someone else's identity and signed their key, you can extend trust through that signature.
Here's how it works in practice. Alice has verified Bob's key in person and signed it. Bob has verified Carol's key in person and signed it. If Alice trusts Bob's verification judgement, she can configure her PGP software to treat keys that Bob has signed as valid. Carol's key becomes valid for Alice through one intermediary.
The trust model has a parameter called trust depth. Depth 1 means "I trust the person I verified to verify others." Depth 2 means "I trust the person I verified, and the people they trust, to verify others." Most people set depth 1 or 2 and stop there.
In practice, the web of trust is less used than it was in the 1990s. The reasons are practical. Keysigning parties require physical attendance. Maintaining signed key lists requires ongoing effort. And the system breaks down when people let their keys expire, lose their private keys, or simply stop using PGP.
The keyservers that held the web of trust also had problems. The SKS keyserver network was taken down in 2019 after a spam attack that flooded it with fake keys. The replacement, keys.openpgp.org, deliberately doesn't publish third-party signatures. It verifies email ownership but not identity. This means the web of trust on keys.openpgp.org is effectively non-functional.
If you're verifying a key in 2026, the practical path is usually the fingerprint check, not the web of trust.
Key revocation and expiry
A key that was genuine last year may not be genuine today. Keys get compromised, lost, or replaced. Two mechanisms exist to handle this.
Revocation certificates: when you generate a PGP key, you can also generate a revocation certificate. If the key is compromised, you publish the revocation certificate to a keyserver, and anyone who refreshes their keyring will see the key is revoked. The problem is that this only works if people refresh. If you cached the key two years ago and never checked again, you'll encrypt to a revoked key without knowing.
Key expiry: setting an expiration date on the key means the key automatically becomes invalid after that date. This forces people to check for a replacement. If someone lets their key expire and generates a new one, you can't encrypt to the old key (your software should warn you) and you need to find the new one.
The practical rule: check the key's expiry date and revocation status before encrypting. If you fetched the key from a keyserver, the server has the latest status. If someone sent you the key directly, you don't have that information unless you also check the keyserver.
What can go wrong
The most common failure is encrypting to a substituted key. This happens when an attacker intercepts a communication channel (email, website, instant messaging) and replaces the legitimate key with their own. If you encrypt to the substituted key, the attacker can decrypt and read the message, then re-encrypt it to the real key and forward it. Neither you nor the real recipient knows this happened.
The only defence is verifying the fingerprint through a separate channel. This isn't optional for high-stakes communication. It's the entire basis of the system.
The second failure is encrypting to an old, compromised key. If someone's key was stolen and they haven't yet published a revocation, you're encrypting to the attacker. There's no technical solution to this beyond the expiry date, which forces periodic renewal.
Practical workflow
For most people, the workflow is: get the key, get the fingerprint from a separate source, compare them, check the expiry date, and encrypt. If the communication is high-stakes, verify the fingerprint over a voice or video call. If you're verifying keys for a team, maintain a shared list of verified fingerprints and update it when people rotate keys.
The web of trust is elegant in theory. In practice, the fingerprint check is what actually keeps PGP secure. Everything else is infrastructure around that single act of comparison.
Once you've verified the key, you're ready to encrypt your message. If you received an encrypted reply, use the decrypt pane to read it. For the full setup walkthrough, see our guide on sending an encrypted email with PGP for free.