Skip to main content

Phishing Analysis — How Market Clones Actually Work

Most market users have heard "verify with PGP" enough times to tune it out. What gets skipped is why it works and what, mechanically, it defends against. Below: how phishing operates at a technical level — starting with why a vanity address that looks right proves nothing — and a comparison of three distinct anti-phishing mechanisms built into active markets, matched to the attacks each one stops and doesn't stop.

A Matching Prefix Is Not a Matching Key

A v3 onion address is a 56-character base32 string that encodes an Ed25519 public key, a checksum, and a version byte. It is not chosen — it's derived mathematically from the key. If you want an address that starts with a specific string, like darkmat... or blackop..., you can't pick it directly. You generate keypairs repeatedly until one happens to produce an address starting with your target prefix, then keep that keypair.

This is called vanity address generation, and it's computationally trivial for anything up to about 8 characters using consumer hardware, and still very feasible at 10–12 characters with a GPU running for a few hours. Every market operator with a memorable-looking address — DarkMatter, DrugHub, Black Ops, all of them — generated many candidate keypairs and kept the one with the address they wanted.

Here's the part that matters for phishing: anyone can do the same thing. A phisher who wants an address starting with darkmat runs the identical brute-force process on their own hardware, generates their own Ed25519 keypair, and ends up with a completely different private key controlling an address that looks just as legitimate at a glance. The prefix matching the real market's address is not evidence of anything except that the phisher spent a few GPU-hours on it. It is never a substitute for checking the full address against a signed canary.

Three Defenses, Three Different Attack Surfaces

Three active markets have each built a distinct on-site mechanism to address part of this problem. None of the three is a complete solution on its own, and understanding exactly what each one stops — and doesn't — matters more than knowing that it exists.

DrugHub's Unique Per-Visitor Links

DrugHub generates a fresh address per session rather than publishing one static address for the market itself. That removes the fixed target a phisher would normally copy. The trade-off is that verification shifts entirely to the entry point — see the PGP key and canary archive for the current entry-point fingerprint. If the entry point itself is phished, the unique-link system provides zero protection, because the victim never reaches the real infrastructure that generates it.

TorZon's Personal Phrase

TorZon shows you a phrase you set during registration, displayed after login on every visit. This is specifically a relay-proxy countermeasure: even if a relay-proxy clone forwards your credentials through to the real market and displays whatever comes back, the phrase only appears if you're actually on TorZon's real infrastructure at that exact moment — a clone that isn't relaying live would show nothing or something wrong. The limitation is timing-specific: it only works after you already have a phrase set, meaning first-time registration on an unverified address gets no benefit from it at all.

Black Ops's Phishing-Proof CAPTCHA

Standard CAPTCHAs can be relayed: a proxy clone shows the victim the real CAPTCHA, the victim solves it, and the proxy forwards the solution to the real site. Black Ops' implementation is built specifically to make that relay harder to execute cleanly, targeting the automation step a relay-proxy clone depends on. It does nothing against a static credential harvester, which doesn't need to relay a CAPTCHA at all — it just needs your typed password.

None of These Replace PGP Verification

Every mechanism above operates after a connection is already made. They reduce what a successful phishing clone can extract, but none of them prevent you from landing on one in the first place. That's still exclusively the job of PGP canary verification — checking the address you're about to visit against a signature you've independently confirmed, before you type anything into it. The three mechanisms above are damage mitigation for the moment verification fails or gets skipped; they are not a substitute for doing it.

If you're unclear on what verification actually involves in practice, the fingerprint and canary cadence for every active market is documented in the PGP key and canary archive, along with the specific mistakes — short-ID matching, circular sourcing — that cause verification to fail even when someone believes they've done it correctly. For the bigger picture of why a signature ends up being the main defense on Tor, see why PGP matters on Tor.