PGP Dark Web Verification: Checking a Signed Address, Step by Step

Why a market's own "encrypt" box isn't the same as encrypting locally

Many markets offer a built-in encryption box: paste your shipping address, click encrypt, and the market's own JavaScript produces ciphertext for you. The problem is structural, not hypothetical — your plaintext address reaches the market's server before it's encrypted, in full, regardless of what happens afterward. If that server is later seized, the plaintext you typed may already be logged, cached, or otherwise recoverable, encryption box or not; this is precisely the mechanism behind plaintext addresses being recovered from seized market servers in past cases. Encrypting locally — composing your message in Kleopatra's own notepad, covered on the PGP guide, and pasting only the finished ciphertext into the market's field — means your plaintext never leaves your own machine at all. The market never needing your plaintext isn't a convenience feature to skip; it's the entire point.

Verifying a signed mirror announcement, in full

1. Locate the market's current signed announcement — typically a post to its Dread subdread, formatted as a cleartext-signed PGP message with a list of current addresses inside it.
2. Obtain the market's public key from a source independent of wherever you found the announcement itself. Never take the key from the same single page handing you the addresses — that page could be compromised or fraudulent as a whole, and no page that hands you both an address and its own verify onion link PGP instructions is actually offering independent verification of anything.
3. Import the key: gpg --import market-key.asc, the same import command covered in full on GnuPG's own manual, or use Kleopatra's Import function with the same file.
4. Before trusting the key for anything, compare its full fingerprint — all 40 hexadecimal characters for a standard key — against a second, independently obtained copy of that same fingerprint. Matching only the first several characters, sometimes called the key ID, is not sufficient; a short ID is a small enough space that a colliding key is a realistic risk to plan around, not a theoretical one.
5. Verify the signed announcement: gpg --verify announcement.txt, or Kleopatra's Decrypt/Verify function pointed at the same file.
6. Only trust an address that appears inside that verified, signed list. Discard anything from any other source, including a search result, a comment, or a "support" message.

What a good signature proves, and what it certainly does not

A good signature proves exactly one thing: the signed content was produced by whoever holds the private key matching the public key you verified, and it hasn't been altered since signing. It does not prove that key belongs to the market's genuine, original operator rather than a well-organized phishing operation running its own convincing Dread presence and its own consistent signing key — verification rules out a cheap, opportunistic clone using no key at all, or a different key entirely; it does nothing about an adversary sophisticated enough to build a complete, internally consistent fake operation with its own real signing key. This is the honest ceiling of what cryptographic verification can do here, and no page that skips stating it plainly is being fully honest with you.

Where a first trusted key actually comes from

This is the hardest, most honestly unresolved question in this entire niche, and every competing guide raises it and then quietly moves on without answering it. If every source you can reach — a directory, a search result, even the market's own Dread post — is itself unverified the first time you encounter it, there is no perfectly clean answer to where a first trusted anchor comes from. The best available approximation, not a guarantee: cross-reference the key across multiple independent sources that have no obvious relationship to each other — a directory, a separate forum, a prior verified announcement from the same key if one exists — and treat convergence across genuinely independent, unrelated sources as more meaningful than any single source's confidence, however official that source looks. A key that's been stable and consistently referenced across a long history is a better bet than a key that appeared for the first time alongside the address you're trying to verify right now. None of that is certainty. It's the realistic best available signal, and pretending otherwise would be worse than admitting the limit.

Comparing a fingerprint properly

Read or copy the entire fingerprint, not a visually distinctive-looking chunk of it. A standard OpenPGP fingerprint under the current specification is 40 hexadecimal characters;^{RFC 9580} comparing only the first 8 or 16 — the "key ID" covered on what is PGP — leaves the remaining characters completely unchecked, and a key ID collision, while not trivial, is achievable for an attacker motivated enough to target a specific, high-value market. The safest comparison method is copy-and-paste between two independently obtained sources rather than reading characters aloud or matching by eye across two windows — visual matching across two long hex strings is exactly the kind of task human attention reliably fails at past the first several characters, which is also exactly where a forged key is designed to diverge.

"BAD signature" or "no public key": what to do

A "BAD signature" result means the content was altered after signing, or you're checking it against the wrong key entirely — either way, do not trust the content, and do not proceed as though a partial or "close" match is acceptable; there is no partial credit in signature verification. "No public key" means gpg doesn't have the signing key in its keyring at all yet — import the correct key first, following the same independent-sourcing and fingerprint-check steps above, then re-run verification; it is not evidence the message itself is fraudulent, only that your keyring is incomplete. Neither error is a prompt to lower your standard or accept the content anyway "just this once" — both mean stop and resolve the specific problem before treating anything in the message as trustworthy.

Handling a rotated or replaced key

Operators legitimately rotate keys — after a suspected compromise, on a fixed schedule, or simply as part of routine hygiene — and a rotation is not inherently suspicious on its own. What matters is how the rotation is announced: a trustworthy rotation is itself signed by the old key, explicitly vouching for the new one, which is called cross-signing and is the one mechanism that lets you carry trust forward from a key you'd already verified to one you haven't yet independently confirmed. A "new key" announcement with no connection to the previous key — no cross-signature, no reference an outside party could check — is functionally indistinguishable from an attacker who's simply decided to introduce their own key, and should be treated with the same independent-verification skepticism as a first-time key you'd never seen before.

A good signature on an expired key: safe, or not?

These are two different facts, and conflating them is a common, consequential mistake. Key expiry is about the key's own validity window, set by its owner when it was created or last extended — an expired key means the software will (correctly) refuse to treat new operations with it as fully valid, regardless of when those operations happened. Signature age is about how long ago the signing actually occurred, which is a separate, independent fact. A signature made while a key was valid remains a legitimate historical record of what was signed and when, even after that key later expires — but a message signed months ago, even with a still-technically-valid signature, may simply be old and superseded by an address rotation you haven't seen yet. Check both facts separately: is the key currently valid, and separately, how recent is the specific signature you're relying on. An old signature on a still-valid key is a currency problem, not a validity problem, and the fix is finding a more recent signed announcement, not distrusting the old one's authenticity.

Does PGP hide who you're talking to, or only what you said?

Only what was said. PGP encrypts message content; it does nothing to hide the metadata surrounding that content — who sent a message to whom, when, and how often, are all visible to anyone positioned to observe the traffic itself, whether that's a market's own server logs or, on the browsing layer, anyone watching your connection pattern rather than its content. Tor is the tool that addresses that separate problem — covered on how onion services work and how Tor works — and the two protections are complementary rather than substitutes for each other: PGP without Tor still exposes who's communicating with whom; Tor without PGP still exposes what's actually being said to anyone who can read the plaintext at either end.

If you've already sent something sensitive unencrypted

Treat the information as disclosed, not as a mistake that can be walked back — once plaintext has left your machine, there's no remote-delete or retraction that reliably removes it from wherever it's already been logged, cached, or read. The forward-looking fix is what matters from here: encrypt everything going forward, including messages in the same conversation, so the damage doesn't compound; if the disclosed information (a shipping address, a real name) creates an ongoing risk, treat that risk as live rather than resolved, and factor it into decisions about that specific transaction or identity going forward — a question that belongs to the same threat-model exercise as everything else here. There's no version of this page that offers a technical undo, because one doesn't exist. The broader habits that keep one disclosure from cascading into a bigger problem — separating identities, minimizing what any single account or vendor ever learns about you — are covered in full on the OPSEC guide, including the worked checklist for exactly this kind of fallout.