Verifying a Vendor’s PGP Fingerprint Against Three Prior Markets: A Reputation Cross-Check Tutorial

The profile said six years, three markets, four thousand orders. The fingerprint said otherwise. Usernames travel. Cryptographic keys do not, unless the holder still controls the private half. This is a research-only method for testing that claim. It is not a buying guide, and it is not a map to any live market.

I treat a vendor username the way I treat a forum handle. Copied, reused, abandoned after a seizure or an exit. Markets themselves get cloned. Directories get phished. The only continuity that survives that mess is a PGP identity you can check against older, independently stored signatures. If you cannot do that check, you do not have a reputation. You have a story.

What you are actually comparing

A PGP public key is a blob of math. The fingerprint is a hash of that blob, printed as hexadecimal. You compare fingerprints, not display names, not “key IDs” shortened to eight characters, not a screenshot of a profile header. Short IDs collide. Names collide on purpose.

The key arrives as ASCII armor, a text block that starts with a BEGIN PGP header so it can be copied through forms and forum posts without turning into binary garbage. If someone sends you a photo of a key, a PDF, or a Word file, stop. Documents are a tracking and malware channel. Paste armor as text or do not use it.

Verification has two layers people constantly mix up.

• Key authenticity: is this the same public key that was bound to that identity on earlier markets, or is it a lookalike posted yesterday.
• Key possession: can the person on the other end produce a fresh signature (or decrypt a challenge) with the matching private key. A copied public key proves nothing. Anyone can scrape armor off an old thread.

The first layer is archival. The second layer is live. You need both. A match on layer one and a failure on layer two is how impersonation actually looks in the wild.

Why three prior markets, not one

One old listing is trivia. Two can be a pair of related clones, or a vendor who rebuilt a shop and a backup shop on the same script. Three separate market histories, each with signed material you can still retrieve, is a higher bar. It is not magic. It is just expensive to fake well.

Markets die. Operators vanish. Law enforcement seizes boxes. The forum layer is what remains. Dread in particular is built around pseudonymous reputation and PGP as identity continuity across sessions. Market staff keep official, PGP-verified accounts there and answer complaints in public. The board outlives individual shops. That is the archive you actually use when a market onion is gone.

I am cynical about that archive too. Mods get it wrong. Phishing threads slip through. An “official” account can be hijacked if the operator’s private key leaked. Treat Dread as a better source than a random mirror, not as a notary.

Before you collect anything

You will be pulling keys off onion forums and directories. Do the boring OPSEC first or the rest is theater.

• Tor Browser security level to Safest. JavaScript stays off. Malicious mirrors use it.
• Do not fetch keys through a clearnet proxy of a directory. Surface pages such as Dark.Fail or Tor.Taxi are watched by your ISP even when the operators are legitimate. Use the onion, and only after you verify the directory’s own signed link list.
• Never download the key as a document attachment. Armor in a <pre> block or a paste is the whole point.
• Verify the directory message with that directory’s published public key before you trust any onion you are about to scrape. A compromised directory can swap every link. Signature check is the counter to that single point of failure.

If the signature on the directory post does not verify, you do not have a research target. You have a phishing page collecting account logins and public keys from people who were about to be careful.

Step 1: Inventory the claim, as a claim

Write down what the vendor asserts, in their words, not yours.

• Current market handle and the full PGP fingerprint printed on that profile.
• Every prior market they name, with old handles if they changed spelling.
• Any Dread username they say is theirs, plus a link to a signed post if they offered one.
• Any story about key rotation, “lost Dread access,” or a new key after a “laptop death.”

Treat rotation stories as hostile until proven. Legitimate rotation is a signature from the old key over the new key, plus a period where both keys are used. “I lost the key, trust the username” is how clones onboard.

Also note what the current market actually stores. Plenty of marketplace scripts let a vendor paste a public key at registration and then never force a challenge. A key sitting in a profile field is an import, not a proof of possession. Some stacks add TOTP or hardware 2FA on the account. That protects the login. It does not bind the login to last year’s key.

Step 2: Recover signed artifacts from each prior market

You are hunting for material that could only have been produced by the private key, dated before the current shop existed.

Useful artifacts, in descending order:

• A PGP-signed product announcement, dispute reply, or canary-style status post, with the full armor intact.
• A Dread post from a PGP-verified account whose fingerprint you can extract and that explicitly names the old market handle.
• A signed message a researcher or buyer saved at the time (your own archive, a colleague’s, a public paste that still verifies).
• A key change statement signed by the previous fingerprint.

Useless artifacts, no matter how official they look:

• Unsigned profile text that recites a fingerprint.
• A review thread that mentions the name but never quotes armor.
• A screenshot.
• A key posted only on the new market, with a paragraph about the old ones.

Work market by market. For each of the three names, you want at least one verifiable signature, not a vibe. If a market is dead and nobody mirrored signed posts, that history is gone. Say so. Do not fill the gap with forum gossip. Dead markets without surviving signatures simply do not count toward the three.

Community boards still help here. Topic areas around OPSEC, specific shops, and harm reduction are where people paste keys when a migration happens. Read those as primary documents. Then verify the armor locally. Do not trust a comment that says “key checks out.”

Step 3: Import locally and print the fingerprint yourself

Do this on a machine that is not your daily driver if you can. I use GnuPG on an offline box. A browser tool such as KeychainPGP will generate modern Ed25519 and X25519 pairs in WebAssembly and claims nothing is sent to a server. That is fine for learning ASCII armor. It is a weaker place to park keys you care about, because you still fetched the JavaScript. For verification of someone else’s public key, offline GnuPG is the less annoying option.

Import the armor from artifact one. Print the full fingerprint. Import artifact two into a separate keyring, or delete and re-import so you do not accidentally “update” a key with attacker-supplied UIDs. Print again. Repeat for the third.

You are looking for exact fingerprint equality. Not “same last eight characters.” Not “same email field.” User IDs on darknet keys are often junk or copied. The fingerprint is the identity.

Outcomes I actually see:

• Three-way match. Same fingerprint on signed material from each claimed prior market. This is the only result that supports a continuity story.
• Match on one, mismatch on the others. They borrowed a real vendor’s old armor for the homepage and invented the rest. Common after an exit, when buyers are hunting a familiar name.
• Match on unsigned profiles, fail on signatures. They can copy a public key. They never produced a signature with it on those markets, or the signatures were stripped by bad HTML.
• Close but not equal. Different key, similar UID. Impersonation, or a real person who rotated and did not leave a signature chain. You cannot tell. Record it as a new identity.

Line wrapping kills more verifications than cryptography does. Forums insert zero-width spaces. Markets strip headers. If gpg --verify chokes, hex-dump the file and look for smart quotes and wrapped checksum lines before you declare a mismatch.

Step 4: Challenge the live key

Archival match is necessary and not sufficient. The person behind the current account must prove they hold the private key that made those old signatures.

Send a unique challenge: a long random string you generated, a date, and a short purpose label, all in one block. Ask for a cleartext signature over that exact block. Do not accept a signature over a different message, a signature of their own manifesto, or a signature they “keep on file.” Replay is the whole attack.

Verify the signature against the key you imported from the old artifacts, not against whatever the new profile is currently serving. If the shop swapped the key between your import and the reply, you want to catch that.

Refusal is a result. A vendor who claims a multi-year identity and will not sign a nonce is asking you to fall back on username reputation, which is the thing this whole process exists to replace. I do not argue with that refusal. I mark the identity as unverified and walk.

Decrypting a message you encrypted to their public key is an equivalent possession test. It is also how a lot of market UIs already work for order mail. If you use that path, still keep the archival fingerprint check. Encryption to a key only proves they hold that key now. It does not prove that key is the one from market two in 2019.

What a fingerprint match does not buy you

This is the part people skip because it ruins the mood.

A three-market fingerprint match does not mean the vendor is safe, honest, or even the original human. It means one cryptographic identity showed up in three places and can still sign. Keys get stolen. Operators get arrested and replaced. A seized laptop with an unlocked agent is enough. Law enforcement has run shops. Admins have quietly handed over keys. Continuity of a key can be continuity of a compromise.

It also says nothing about escrow behavior. Markets still hold funds in ordinary escrow, or in 2-of-3 multisig, or they push finalize-early once a vendor looks “established.” FE is a trust decision layered on top of identity, and it is a bad one unless you already had reasons that survive this check. Direct deals skip the market’s dispute window entirely. A verified key does not make DD a good idea. It just means you know who you are being reckless with.

Reviews remain gameable. Scripts track scores and auto-suspend on chargebacks. Those numbers live inside one operator’s database. They do not travel with the key unless you independently saved the signed disputes.

Failure modes that keep wasting time

The truncated profile fingerprint. Some themes print 16 characters and call it done. Never record that as the identity. Open the full key, import it, hash it yourself.

The helpful re-uploader. A third party “helpfully” posts the vendor’s key on Dread after a seizure. Maybe it is right. Maybe it is a swap. Only signatures from before the chaos count, or a live challenge from an account you already bound to the old fingerprint.

UID cosplay. Attacker imports the real public key, adds a new user ID, and re-uploads. Your client may display the new name in bold. Fingerprint is unchanged, which is good, but the display is lying about ownership of the new UID unless that UID is self-signed in a way you actually checked. Look at signatures on the key, not the friendliest name in the list.

Directory confusion. People verify Tor.Taxi or Dark.Fail, then assume every vendor key linked from a thread on those pages is equally signed. Directories attest to onions. They do not attest to vendor identities. Separate checks.

Canary worship. Signed canaries prove an admin still controls a key at interval T. They do not prove the vendor you are researching is the same person who posted on a dead market. Different keys, different jobs.

The six-month silence. A perfect three-way match from years ago, then no signatures during a long gap, then a sudden return. Possible. Also the pattern of a recovered database plus a cloned storefront. Demand a fresh challenge. Then decide whether the gap itself is acceptable. I usually want signed activity on both sides of a seizure, not only before it.

A working verdict

Cross-checking a vendor PGP fingerprint against three prior markets is the least bad identity test this ecosystem has. It is also narrow. It catches the lazy clone, the username squatter, and the shop that pasted someone else’s armor into a Laravel vendor form. It does not catch a stolen key. It does not catch an operator cooperating with a seizure. It does not turn finalize-early into a reasonable default.

Run the directory signature check so you are not scraping a honeypot. Pull real armor from three independent histories, or admit you do not have three. Import each key yourself. Compare full fingerprints. Challenge the live account with a nonce you generated. Write down mismatches as mismatches instead of writing a novel about how the old market “probably used a different key.”

If any of those steps fail, the reputation you were offered is not portable. You are looking at a new identity that happens to know the lore. For research, that is still useful data. For anything that assumes continuity, it is a stop.