PGP for Darknet Buyers — Signing, Verifying and Spotting Fake Keys

PGP on the darknet is rarely about the encryption itself. The math is solid; the failure modes are almost always human, operational, or social. For buyers, the practical skill isn’t just knowing how to paste a public key into Kleopatra—it’s understanding the trust model, recognizing phishing vectors, and verifying identities cryptographically before any money moves. This guide focuses on the three things that matter in practice: signing messages, verifying signatures, and spotting the fake keys that are the primary attack vector against new users.

## The Two-Key System, Applied to Vendor Trust

The core model is simple asymmetric encryption. A vendor posts a public key on their profile—an “open padlock” anyone can use to encrypt a message. The corresponding private key—the only key that unlocks it—stays on the vendor’s offline machine. When you encrypt a message to a vendor, you’re using their public key. When you receive a signed message from them, you verify it with that same public key. This is functionally identical to the whistleblower-journalist workflow described in many guides, but the stakes are different: a journalist verifying a source is protecting a conversation; a buyer verifying a vendor is protecting their money and their identity.

The problem is that this system relies entirely on the authenticity of the public key itself. If a threat actor substitutes their own key for the vendor’s genuine one, the entire cryptographic house of cards collapses. You’ll encrypt your address to the attacker, and they’ll decrypt it, read it, and potentially use it against you. The math is unbreakable; the key distribution is not.

## How Signing Actually Works

Signing is distinct from encryption. Encryption protects confidentiality—it scrambles the message. Signing provides authentication and integrity—it proves the message came from the holder of the private key and wasn’t altered in transit. When a vendor signs a message, they generate a hash of the text, encrypt that hash with their private key, and attach it as an ASCII-armored signature block. The recipient decodes the signature using the vendor’s public key, computes the message hash independently, and compares the two. If they match, the signature is valid. If the message was altered by even one character, the hash will differ and the signature will fail.

In practice, on darknet markets and forums like Dread, vendors and market admins use PGP signatures to prove identity continuity. The karma system builds pseudonymous reputation over time, and PGP verification allows users to prove identity continuity across sessions. This is crucial because market admins will often publish signed canary messages at regular intervals—announcements proving they remain in control of their private keys and haven’t been compromised by law enforcement.

For buyers, the workflow is as follows: a vendor posts a message, perhaps a product update or a change in terms. They include a PGP signature. You copy the entire message text exactly, including every line break, paste it into your PGP software (Kleopatra on Windows, GPG on the command line), and select “Verify.” If the key is already in your keyring, you’ll get a “Good signature” confirmation. If the key isn’t trusted—meaning you haven’t explicitly verified its authenticity through a separate channel—you’ll get a “Good signature from unknown key” or a warning about the key being untrusted.

## The Critical Distinction: Signature Validity vs. Key Authenticity

This is where most users go wrong. A valid PGP signature proves the message was signed by the private key corresponding to the public key. It does not prove that the public key belongs to the vendor you think it does. A phishing attacker can generate their own keypair, sign a fake announcement with it, and the signature will be perfectly valid—but it’s valid for the attacker’s key, not the vendor’s.

To establish key authenticity, you need an out-of-band verification. The most reliable method in the darknet ecosystem is the signed link list. Directories like Dark.fail and Tor.Taxi publish their .onion links with PGP signatures. The directory generates a message containing the new .onion links and cryptographically signs it with their private key. You, the user, verify that signature using their public key. If the signature matches, you know with mathematical certainty that the link was provided by the real administrator and not a hacker who compromised the website. This is why the standard guidance is to never trust a single point of failure—if a hacker compromised the Tor.Taxi server, they could swap legitimate links with phishing mirrors. The PGP signature prevents that, but only if you have the genuine public key from a trusted source, ideally obtained through multiple independent channels.

The same logic applies to vendor keys. A vendor’s PGP key posted on a market profile is the starting point, not the verification. The safest approach is to find the vendor’s key cross-posted across multiple venues—their profile on Dread, a signature in a forum post from months ago, a key in a PGP key server. If the fingerprint matches across all sources, the key is likely genuine. If it differs anywhere, assume it’s a fake.

## Spotting Fake Keys: What to Look For

Fake keys are the most common tool for low-effort phishing on darknet markets. The attacker creates a keypair with a name matching a trusted vendor, posts it on a lookalike market or a phishing forum account, and waits for buyers to encrypt their shipping addresses to it. There are several telltale signs.

First, check the creation date. A vendor who’s been operating for two years will have a key created long ago. If a “vendor” suddenly has a brand-new key, that’s a red flag—legitimate vendors typically keep their keys stable for years, and abrupt key changes are usually announced with a signed message from the old key. A new key with no continuity is suspect.

Second, check the fingerprint and key ID. You can see the full fingerprint in your PGP software. Compare it to any known references—the vendor’s key fingerprint mentioned in a Dread post, a screenshot from a verified account, or a key ID posted in a vendor’s shop description. Phishing keys will have different fingerprints.

Third, examine the key’s subkeys and expiration. Reputable vendor keys often have an expiration date and no extraneous subkeys. A key with odd structure or a very long (or infinite) expiration can indicate a hastily generated throwaway key.

Fourth, and this is critical, check the key’s trust path. In OpenPGP, you can sign someone’s key to indicate you’ve verified their identity. If a vendor’s key is signed by other well-known community members—market admins, long-standing forum users, or other vendors—that’s a strong signal of authenticity. If the key has zero certifications, it’s either new or not widely trusted.

Finally, watch for the “mirror site” attack. The context notes that directories like Tor.Taxi and Dark.fail exist to protect against phishing mirrors. Before using a search engine to find a marketplace, check trusted directories that provide PGP-verified .onion links to ensure you’re visiting the real forum and not a hacker’s mirror site. A fake market will often list a vendor’s real PGP key (scraped from the genuine site) but a fake wallet address—the key is genuine, but the payment goes to an attacker. This is a variation on the fake key attack, and it’s why you should always verify the wallet address using PGP-signed messages, not just the key.

## Practical Workflow for Buyers

Here’s a concrete, step-by-step OPSEC process for handling PGP when dealing with a new vendor:

1. Obtain the vendor’s key from multiple independent sources. Check their market profile, their Dread account, any PGP-signed posts they’ve made, and any external directories. Compare fingerprints. If they only match on one source, consider that source potentially compromised.
2. Import the key into your keyring and study its metadata. Check creation date, expiration, subkeys, and any certifications from known community members. Verify that the UID (the name/email attached to the key) exactly matches the vendor’s known handle.
3. Send a test message. Encrypt a non-sensitive message to the vendor’s public key and ask them to decrypt it and respond. If they can’t decrypt it, something is wrong—either the key is fake or the vendor’s setup is broken. Never send a real shipping address in a test.
4. Verify all market-critical messages. When you receive a signed message from the vendor (e.g., a confirmation of payment, a change in terms, or a request for additional information), verify the signature. If it fails, treat it as a malicious message and contact the vendor through an alternative channel to confirm.
5. Use market-issued PGP for wallet verification. When depositing funds, the market should have a signed message or a PGP-verifiable wallet address. If the market doesn’t provide this, consider it a red flag and investigate before sending money. Remember that multisig escrow requires multiple parties’ signatures to release funds; a false wallet address defeats this protection.

The deeper truth is that PGP verification is a social process, not just a technical one. Trust is built through cross-referencing, through the web of signatures, and through the public records of the community. The “trust but verify” ethos is baked into the culture of forums like Dread, where PGP verification allows users to prove identity continuity across sessions and where market admins publish canary-signed announcements at regular intervals. These are the mechanisms that make the darknet function despite the constant threat of phishing, seizure, and exit scams.

Fake keys are a solvable problem, but only if you treat PGP as part of a broader verification routine rather than a magic bullet. Check the key. Check the signature. Check the fingerprint against multiple sources. And never, ever skip the out-of-band verification. The math is on your side; it’s the human errors that will get you.