PGP in Practice, Part 7: When PGP doesn't help you
Wajahat Ali··9 min read
Endpoint compromise, metadata correlation, fingerprint verification failures, no forward secrecy, coerced disclosure — the threat models PGP wasn’t designed to address. Plus a triage table for what to use instead (Signal, SecureDrop, MLS, age, magic-wormhole) when the threat exceeds what PGP covers.
If you've followed Parts 1–6, you can send and receive encrypted mail from any of the four major clients, generate a properly-structured key, and reason about the cryptographic guarantees PGP provides. This final part is the threat-model walkthrough — the cases where someone did everything right and still got compromised, because PGP wasn't designed to defend against the threat that actually mattered.
The point is not to talk you out of using PGP. It's to set realistic expectations and to point at what to reach for in addition when the threat model exceeds PGP's design.
PGP encrypts a message at rest in transit. It does not protect a message at rest on either endpoint.
If your laptop is owned by malware — a state-sponsored implant, a criminal RAT, a malicious browser extension, or a supply-chain compromise of any tool with read access to your home directory — the attacker reads your mail at the moment you decrypt it. The PGP layer is invisible from the attacker's perspective; they're reading plaintext in your mail client's window after the gpg-agent has done its work.
This is not theoretical. Documented examples include:
Journalists and activists targeted by Pegasus (NSO Group), where the iPhone or Android device was rooted entirely. Encrypted communications on the same device were trivially readable.
Operation Aurora and subsequent state-actor campaigns, where browser exploits placed implants on the endpoint and exfiltrated correspondence regardless of transport encryption.
Supply-chain compromises like the SolarWinds incident, where the attacker had administrator access to internal systems — encryption between systems didn't help.
Mitigations are not a PGP thing. They are an endpoint-security thing: hardware-rooted boot (Secure Boot, Touch ID Secure Enclave), application sandboxing, principle-of-least-privilege user accounts, separate machines for sensitive correspondence, hardware tokens for keys (so even an owned laptop can't extract the secret material). For the highest-stakes work, the answer is often a separate device used for nothing else.
PGP encrypts the message body and attachments. It does not encrypt:
The From and To headers.
The line.
Subject
The Date header.
The Message-ID and threading headers (In-Reply-To, References).
The message size.
The timing of when you sent / received it.
The IP addresses involved in delivery.
All of these are part of the SMTP envelope, exchanged in plaintext between mail servers, logged by every hop, and routinely retained for years by mail providers. A subpoena, a national-security letter, or a leak from inside the provider yields all of it — even when the body is opaque.
The Snowden disclosures included documentation of XKEYSCORE, a tool that indexes mail metadata at scale and lets analysts query "all mail to X over the last 6 months" without needing to read a single body. PGP does nothing about this — the metadata correlation alone is often sufficient to identify sources, journalists' contact networks, and activists' affiliations.
The mitigations:
For the metadata that matters most (who you're talking to), use Tor + a drop-site (SecureDrop is the canonical one for journalists). The traffic between you and the drop site goes through Tor's onion routing, hiding the participants.
For real-time correspondence with metadata privacy, use Signal — the Signal protocol blinds the server to who is messaging whom (sealed sender), and the metadata leakage is far smaller than SMTP's.
For one-shot file transfer where metadata matters, use OnionShare or magic-wormhole over Tor. Same metadata-blinding properties.
PGP authenticates the holder of a key, not the human you think you're emailing. If you import the wrong key as your colleague's, every encrypted message you send "to your colleague" is in fact encrypted to whoever owns that key — and every signature you verify is theirs, not your colleague's.
This is the most subtle PGP failure mode because the user-facing experience looks identical to the correct case. Both messages render with green checkmarks. Both go through. The only difference is the underlying key fingerprint, which most operators never check.
The historical example most often cited: Glenn Greenwald's failed PGP setup before the Snowden disclosures. Snowden tried to communicate with Greenwald using PGP and Greenwald couldn't get it working — Snowden eventually recorded a video tutorial walking Greenwald through it. The video was successful, but it surfaces a wider point: even people who know PGP exists and want to use it correctly often fail at the trust establishment, because verifying a fingerprint over a non-PGP channel feels redundant. It is not.
The mitigation is mechanical: every imported public key gets a fingerprint check before you trust it. The fingerprint is verified through a channel that doesn't involve email — face-to-face, a phone call where you read 40 hex characters aloud, a Signal message, or a key fingerprint published on a website you trust over HTTPS with a certificate you've checked. SpidyOps publishes its security key fingerprint at the top of /security; compare what your client computed locally against what's there before sending us anything sensitive.
If you skip the fingerprint check, you are trusting whoever served you the key — which might be your mail provider, a key server, an attacker on the network, or your sender's actual mail account. Most of those are fine; one is not, and you cannot tell which without out-of-band verification.
Modern messaging protocols (Signal, MLS, the WhatsApp protocol, iMessage) provide forward secrecy: the property that compromising today's keys does not let an attacker read yesterday's messages. They achieve this by deriving a fresh per-message key from a chain that's continually rotated; old keys are deleted shortly after use.
PGP has no forward secrecy. The same private key decrypts every message ever encrypted to you. Compromise that private key — by stealing the laptop, the YubiKey, the backup, or coercing the passphrase — and the attacker can decrypt every PGP-encrypted email you've ever received that they can also obtain (from your provider's storage, your archived backups, intercepted in transit a decade ago).
This is the property that makes PGP unsuitable for high-stakes correspondence with a long archive horizon. If you're a journalist whose source archive contains messages from years past and the source's identity must remain protected indefinitely, the right tool is Signal disappearing messages plus a clean device, not PGP.
The mitigation inside PGP's model: rotate keys (Part 6's expiry policy), keep the primary key offline so subkey compromise alone is recoverable, and treat your PGP archive as a vulnerable asset — encrypt the archive with a different key (e.g. age + a hardware token), so a PGP-key compromise alone doesn't unlock the historical record.
A subpoena, search warrant, court order, or border-stop can compel you to decrypt. The legal landscape is jurisdiction-specific:
US: 5th Amendment case law on whether passwords are testimonial is mixed — some courts have held that compelled disclosure violates the right against self-incrimination; others have held that providing the password is a "foregone conclusion" and required.
UK: RIPA Section 49 explicitly criminalises refusal to decrypt on demand from law enforcement, with up to 5 years' imprisonment.
France, Germany, Australia: each has variants of the UK rule.
Border crossings (US, UK, Australia, Canada): customs agents have broad authority to demand device unlocks; refusal can result in seizure of the device.
PGP cannot defend against this — by design, the holder of the private key can decrypt. The mitigations are:
Travel without the key. Generate a travel-only key for the trip, leave the primary at home. If asked to decrypt, you have nothing to give.
Plausible deniability via hidden volumes (VeraCrypt's hidden-volume feature, though law enforcement awareness of this technique is high).
Legal counsel before crossing borders with sensitive material. The legal answer dominates the technical one in this scenario.
PGP encrypts. PGP does not protect against the holder being compelled.
A short triage table for the threat models PGP doesn't fit:
Real-time messaging, especially mobile, especially with forward secrecy. Signal.
High-metadata-sensitivity work (journalists + sources, whistleblowers). SecureDrop, Tor + drop-site, Signal disappearing messages.
Group conversations where every member must be able to read history. Signal Groups, MLS-based clients (when widely deployed), or a shared encrypted document store (Cryptpad).
One-off file transfer. Magic-wormhole, OnionShare, or age + an out-of-band-shared key — simpler than PGP and forward-secret if you discard the key after.
Software releases, code commits, public statements — anything where the message is meant to be public but authenticity matters. Sign with PGP, but also publish via a verifiable channel (signed website with a CT-logged TLS certificate, software release on a platform that records provenance like sigstore).
Long-archived correspondence where forward secrecy matters. Don't use PGP for the archive layer. Use it only for transport, then re-encrypt the archive with a forward-secret protocol (age with a fresh key per archive) and discard the PGP-decrypted plaintext.
This concludes "PGP in Practice." If you've made it through all seven parts, you should be able to send and receive encrypted email from any of the four major clients, generate and back up your own key, and reason about when PGP is and isn't the right tool. The seven-part series is intentionally designed to be read in order, but each part stands on its own — feel free to bookmark Part 6 (key generation) and revisit it whenever you spin up a new key, or Part 7 (this part) when you find yourself reaching for PGP to solve a problem it wasn't designed for.
For vulnerability reports against SpidyOps, the public key remains at /keys/security.asc (fingerprint DA35 104C F168 0A5D 9907 124C 372D 5C34 60AD AF0A). PGP-encrypt anything that includes credentials, tokens, or working exploits. For everything else — casual correspondence, real-time chat, coordinating an engagement — Signal is the better tool.