PGP Key Management — Rotating, Revoking and Backing Up Keys

Most operators on the darknet have a functional grasp of PGP. They know it uses two keys — a public padlock you hand out and a private key that unlocks the box. They generate a keypair, paste the public key onto their marketplace profile, and encrypt their address to vendors. Then they use that same pair for three years, through 500 transactions, across multiple identity pivots, and wonder why they end up on an OSINT analyst’s timeline.

The math never fails you. The operational security around the keys does.

Pretty Good Privacy has been around since Phil Zimmermann developed it in 1991, and its current specification (RFC 9580, which obsoleted the older RFC 4880) still describes a system that is, to the best of publicly available information, computationally unbreakable. The weakness is never the algorithm. It’s the fact that your public key is a unique string of characters, searchable, citable, and linkable to every single account you’ve ever attached it to. Understanding key rotation, revocation, and backup is not a nicety, it’s the difference between a clean exit and a forensic reconstruction of your entire operational history.

Your Public Key Is a Fingerprint, Not a Username

The core misunderstanding is treating your PGP public key like a username — a static handle that identifies you. In reality, it’s a cryptographic fingerprint. OSINT investigators use specialized search engines to track a specific public key across the internet. If an operator named “ShadowBroker” posts a public key on a Russian forum in 2026, and an investigator searches for that exact key, they might find it in an old Reddit comment from 2018 under a real name.

This is how the encryption gets bypassed — not by breaking the math, but by tracking the unique string that you’ve left lying around. The public key becomes a digital fingerprint linking your real identity to your darknet activity. If you’ve used the same key across five marketplaces, two forums, and an old surface-web account, you’ve essentially written an autobiography for anyone patient enough to assemble the pieces.

The practical takeaway is brutal: treat each public key as a disposable identity. It should never outlive a single operational role. The moment you pivot from one marketplace to another, from one vendor alias to a new one, you need a new keypair. There is no reason to carry a key across identities. The old key gets archived, if it needs to be preserved for existing encrypted messages, and the new identity starts clean.

Rotation: The Schedule Nobody Keeps

Key rotation isn’t just about periodic replacement — it’s about knowing when to rotate and having a low-friction process that doesn’t push you to skip it. A sensible minimum schedule is every 90 days for an active operator. If you’re a vendor handling dozens of messages daily, consider 30 days. The cost of rotation is small: generate a new keypair, update your profile, tell your existing contacts to use the new key for anything time-sensitive.

But here’s the operational subtlety — never rotate a key without a reason that’s visible in the marketplace. If you’re a vendor with 500 customers and you suddenly swap your public key, that’s a red flag. It’s what an account takeover looks like. It’s what someone who’s been compromised looks like. The marketplace community will notice, even if they don’t say anything.

So rotation needs to be either organic (scheduled, predictable, and announced) or reactive (a response to a known compromise). For organic rotation, issue a signed message with your old key, stating the new key’s fingerprint and the date of the switch. This establishes a cryptographic chain of trust — your old key certifies the new one, so customers can verify continuity. For a market that supports PGP-encrypted messages or dedicated encrypted messaging interfaces (which most professional scripts do, per the core marketplace components observed in commercial darknet scripts), this handoff is seamless.

Revocation: The Tool You Never Want to Need

Revocation is your emergency brake. A revocation certificate is a small file that tells the OpenPGP ecosystem “this key is no longer valid, stop using it for encryption going forward.” You should generate this certificate at the moment you create the keypair, and store it somewhere separate from the private key.

Why? Because the only time you need a revocation certificate is when your private key is compromised or your device is seized. And in exactly that scenario, you won’t have access to the device where the key lives. You need a copy of the revocation certificate in a secure location — a hardware wallet, an encrypted USB stick stored in a different physical location, or a dead-man’s-switch service that publishes it on a timer.

The mistake most people make is never generating a revocation certificate at all. Or, if they do, they store it on the same encrypted drive as the private key. That’s like keeping the spare key to your house under the doormat. If you lose the device, you lose the ability to revoke — and anyone who finds the private key can impersonate you indefinitely.

When to actually revoke:

• You suspect your device has been accessed by someone else (even briefly — a laptop borrowed “for five minutes” is enough).
• You’ve discovered your passphrase in a breach dump or a keylogger log.
• You’re permanently abandoning a marketplace alias and want to sever the link to your old key.
• Law enforcement has seized a device that contains your private key — published revocation immediately limits what they can do with it, even if they’ve already copied the key material.

A revoked public key is not a protection against existing encrypted messages — those are still readable by the actual holder of the private key. Revocation only prevents future encryption to that key. If investigators have your private key and passphrase, revoked status doesn’t stop them from decrypting old messages they already captured. But it does stop new messages to that key, which matters if you’ve recently pivoted roles.

Backups: The Fine Line Between Resilience and Liability

Think about the physical compromise vectors. The most reliable way to lose control of your PGP identity isn’t an algorithm break — it’s a stolen laptop, a hardware failure, or a seizure. Backing up your private key is essential for resilience, but the backup itself is a liability. A backup of your private key is a copy of your master key, and each copy multiplies your attack surface.

Rule one: never back up a private key to a cloud service. Not encrypted-at-rest Google Drive, not a email attachment, not a note-taking app. If you’re using a cloud provider that can read your files, you’re one empty password field away from handing your entire identity to the provider, their security team, or law enforcement.

Rule two: the backup needs to be encrypted, separately, with a different passphrase than the key itself. If an attacker gets your backup file, they still need the passphrase to access the key. The default encryption for OpenPGP private keys uses a symmetric algorithm — with the right passphrase quality, that’s workable protection.

Rule three: store the backup in a physically secure location. A hardware token (like a YubiKey or a dedicated smartcard) is the gold standard for daily use — it authenticates without the key ever leaving the device. For a cold backup, an offline USB drive or a paper printout of a QR-encoded key works.

What about the marketplace scripts? Here’s a systematic flaw: many marketplace registration flows offer an optional “PGP public key import” and two-factor authentication via TOTP or hardware keys. But account recovery is often via email — which creates a fallback authentication path that’s weaker than the PGP key itself. If the marketplace supports account recovery via email, your PGP key is only as strong as your email account. Don’t let that be the weak link.

Practical Management: The Workflow That Works

Here’s a concrete workflow for an operator who takes this seriously.

Creating a new keypair: Generate keys on an air-gapped machine or a dedicated offline computer. Use Gpg4win or MacGPG (or the command-line gpg tool) with a strong curve — RSA 4096 is standard. Set a passphrase that is long, unique, and not related to any other passphrase you use. Write down the passphrase on paper and store it in a safe — but treat the paper as a high-value asset. Generate a revocation certificate immediately and store it separately.

Daily use: Use a hardware token that holds the private key, if your threat model allows it. This prevents the key from being copied to the machine where you’re reading messages. If hardware is impractical, at least export the key into an encrypted container (VeraCrypt or LUKS) that you only mount for the duration of a decryption session. Never leave the decrypted private key resting on your main operating system.

Rotation schedule: Mark a calendar, but with a twist — set the rotation date as a recurring event every 90 days. When it fires, generate a new keypair, update the marketplace profile, and post a signed announcement. If any of your contacts use the old key to send encrypted messages after the switch, they’ll fail decryption on your side; that’s acceptable collateral damage for good hygiene. Actually, you should still hold onto the old private key’s passphrase until the messages stop flowing — typically two weeks after rotation.

Compromise response: The moment you suspect compromise — a weird login attempt, a marketplace that demands you re-verify PGP possession, a strange file on your device — execute the emergency plan. Publish the revocation certificate. Generate a new key. Contact the marketplace admins (via a different channel, if possible) to flag the situation. Assume that anything sent to the old key after revocation is readable by the attacker.

The OSINT Blind Spot

Get this: the investigators don’t care about your rotation schedule. They care about your discarded keys. When you rotate, your old public key doesn’t vanish — it stays searchable in old forum posts, marketplace profiles, PGP key servers, and cached pages. That old key, combined with any context you left on it (an old username, a unique passphrase fragment, a correlation with a shipping address), is an investigative goldmine.

So rotation works only if you also remove the old key from active contexts. Delete it from forums you control. Remove it from marketplace profiles. If a forum doesn’t allow deletion, overwrite the post with a notice that the key is revoked and irrelevant. What you can’t delete, you can at least revoke and disown. SEO-savvy investigators will find the old posts regardless, but if the key is revoked and you’ve distanced the identity, the chain breaks.

Revocation is also your defense against the “compromised appliance” pattern seen in enterprise security. When a SonicWall SMA appliance was hit with zero-click attacks, the recommended response was factory reset, credential rotation, and restoring only a known-good pre-exposure configuration. PGP is no different — if your device is compromised, treat the key as burned. Even if you’re unsure, the cost of rotating keys is trivial compared to the cost of a burned identity.

One final point, grounded in the reality of darknet marketplaces. The systems you use — the market scripts, the forums, the messaging platforms — are designed to make your life easier, not necessarily more secure. When a marketplace says “PGP encrypted messages,” it often means the encryption is applied client-side, which is fine — the operator can’t read the contents if it’s done properly. But the marketplace operator can see when you log in, how often, and from which exit nodes. They can correlate your key’s usage pattern with your account’s behavior. Your PGP key management is only one layer of a much larger opsec stack.

Rotate religiously. Revoke without hesitation. Back up only what you can’t rebuild. And never, ever let a public key become a permanent fixture of your identity — because in the hands of a skilled OSINT analyst, that key is the thread that unravels everything else.