DrugHub PGP Verification & Anti-Phishing Guide: Why Mirrors Rotate, Checking Signatures & How to Avoid Clones

1. DrugHub onion mirrors and changing addresses

What a link tells you about a mirror

A market link is a URL someone shares. The .onion host within it is a specific Tor address, typically 56 base32 characters in v3. Another address may claim to serve the same site. A matching design tells you nothing about whether the same people control both addresses.

Platform documentation specifies separate vendor and customer backends. Vendors receive private mirrors, and eligible customers can request two. Private addresses should stay out of public directories, though these rules do not measure uptime.

Why an old address might disappear

Unique addresses reduce load on shared entry points. Public links can also be retired, but platform documentation specifies no daily rotation schedule. When an old bookmark fails, verify any replacement; an address that loads may still serve copied content.

Before using a replacement link

Static directories can index old links, but they cannot tell you who operates one today. Verify a replacement against signed text and a full key fingerprint obtained independently of the proposed address. Whether the old link loads is irrelevant to that check.

2. PGP encryption and signature verification

Encryption, signing and who can read a message

In public-key cryptography, the public key is shared; the private key stays protected. OpenPGP may compress text with ZLIB, encrypt it with an AES-256 session key, then wrap that session key for an RSA recipient. The exact algorithms depend on the keys and configuration; Ed25519 is used for signatures, not RSA-style encryption.

A digital signature confirms that a particular private key signed the exact bytes you checked. Independent evidence of who owns that key is still your responsibility. Platform rules describe end-to-end encryption for messages, except generic system messages, and include staff as recipients during disputes. Those rules alone cannot establish what a website's encryption form actually does to your data.

Check the full fingerprint, not the key name

Anyone can assign a familiar name to a key. An eight-hex-character short ID exposes only 32 bits and can collide with another key, as the Evil 32 project demonstrated. A v4 OpenPGP fingerprint is 40 hex characters; compare every one of them against a record you already trust independently. Newer key formats may use longer fingerprints.

GnuPG (GNU Privacy Guard) or Kleopatra can display the imported key's fingerprint. If the same page supplied both the key and the fingerprint, you have only confirmed that they agree with each other, not that the key belongs to who you think it does. A valid signature under that key cannot establish the owner's identity.

Check the signed mirror list

Compare the signer's complete fingerprint with an independent record first. Then verify the signature over the exact list you received, and confirm the full intended address appears inside the signed text. An address pasted outside that signed block has not been signed.

Verify files locally Copy commands

$ gpg --import pgp.txt

$ gpg --fingerprint

$ gpg --verify mirrors.txt

The commands above use pgp.txt and mirrors.txt as example filenames, not live endpoints. For a detached signature, supply both the signature file and the signed file; Kleopatra's Decrypt/Verify can run the same check locally. Stop if GnuPG reports BAD signature. A Good signature still requires a signer whose identity you have established independently.

When copying ASCII-armored text, preserve the BEGIN and END lines along with any headers. Missing lines or altered spacing can break verification entirely. A "verified" badge displayed on the page proves nothing. If the signing key changes, trace the connection to the old key through a source you already trust.

3. DrugHub phishing copies and misleading trust signals

Copied pages can pass a real login challenge

Search results, directories, and unsolicited messages can all point to a copied page. Its layout and status notices may look entirely familiar. Check where the address actually came from and who signed it before proceeding.

A reverse-proxy clone can relay a genuine PGP login challenge while quietly altering what you see. It may substitute a public key or a payment address. Your login can appear to succeed even though the session began on the clone.

Lookalike addresses and directory pages

An onion-address lookalike may match the first and last few characters you remember. Check the full host against signed text. On ordinary web domains, homograph attacks use visually similar characters; clearnet directories also carry DNS and SSL spoofing risks. A directory's padlock authenticates its own web connection, not the onion links it publishes. V3 onion hosts use a restricted base32 alphabet, so partial character matches and copied pages are the more relevant threat.

What a page can claim, and what you can verify

A copied page can carry its own mirror list, signature, and uptime badge. Check the signed address against a key you trusted before encountering that page:

4. Check a link source and respond to a suspect visit

Where did the address and signing key come from?

Record who supplied the address and how you established the signer's identity before you checked the page. Compare the full fingerprint and verify the signed address locally. If either check fails, stop. The page under investigation cannot vouch for its own key.

Platform rules state "Support only on market" and prohibit external contacts. They name Support Chats as the on-platform channel. Report a suspect address there only if you already have access to a separately verified destination. Otherwise, keep the evidence offline. An off-site "support" account has no standing to request credentials or personal details.

If you opened a suspect page

Close it immediately and stop using anything it offered, including downloads and payment requests. A new Tor identity ends the local session, but information already submitted stays with whoever received it. Write down the address and what you entered before closing, without reopening the page.

If you sent private data, determine which accounts or keys need replacing. For an exposed private key or passphrase, generate a new key in a trusted environment and revoke the old one where appropriate. Replacing the key will not undo earlier disclosure. Part 1's account-access section explains the limits of recovery.

Mirror verification and phishing: common questions