Verifying Dark Web .onion Links

An .onion v3 address is derived from an Ed25519 public key - it is mathematically bound to the service's private key. This means there is exactly one legitimate .onion address for each unique private key. No two legitimate services share an .onion address. However, the existence of a valid .onion address does not guarantee the service is who it claims to be - anyone can create a new private key and .onion address and impersonate another service on that new address. Vanity .onion addresses: using tools like mkp224o, attackers generate .onion addresses that start with the same characters as a legitimate service. For example, if the legitimate service starts with 'abcdefg', the attacker generates 'abcdefh...' (very close but different). Users copying .onion addresses must verify the full address, not just the prefix. The same vanity generation technique is legitimate for services creating recognizable addresses (e.g., starting with 'secure' or 'private') - the difference is intent.

Legitimate .onion services publish signed lists of their addresses. The service operator signs the .onion address with their PGP/GPG key. Users verify the signature against the operator's published public key. This process: (1) Find the service's PGP public key from a trusted, independent source (their clearnet website before going .onion, a trusted community, or key servers). (2) Download the signed address statement from the service. (3) Verify the signature: gpg --verify address.txt.asc address.txt. If verification succeeds and the PGP key matches the trusted copy, the .onion address is legitimate. This process is only as strong as the trust in the initial public key. If the initial source of the public key is compromised, the chain of trust fails. Use multiple independent sources to obtain the public key when possible.

Discovery methods with different trust levels: (1) Service's own clearnet website (HTTPS, with valid certificate): the organization publishes their .onion address on their verified clearnet site. Examples: Facebook's .onion (facebookwkhpilnemxj.onion), ProPublica's .onion. These are verified because the clearnet site's HTTPS certificate establishes identity. (2) Official documentation: Tor Project, Freedom of the Press Foundation, and similar organizations publish verified .onion address lists in their official documentation. (3) The Hidden Wiki and link aggregators: these are community-maintained and have no verification mechanism. Links may be outdated, replaced with phishing versions, or simply wrong. Use with caution. (4) Forum recommendations: links shared on clearnet or .onion forums by individual users have no verification. Require cryptographic signatures from the service operator before trusting. (5) Dark web search engines (Ahmia): Ahmia crawls .onion sites and provides search. It does not verify site identity - it only confirms the site exists and responds.

Safe .onion bookmark practices: (1) Bookmark immediately after cryptographic verification, not before. (2) Use Tor Browser's bookmark system (not the operating system's, which might sync to clearnet services like browser sync). (3) Include the verification date and source in the bookmark description (e.g., 'Verified 2025-01 via signed announcement on official clearnet site'). (4) Periodically re-verify critical bookmarks - legitimate services occasionally rotate their .onion addresses and announce new addresses via signed statements. (5) Do not share .onion links via clearnet messaging (links sent via SMS, email, or social media create records of your interest in specific .onion services). Share via end-to-end encrypted channels (Signal, Element/Matrix, or in-person). For reference: store .onion addresses in an encrypted file (GPG-encrypted text file, KeePassXC database, or Bitwarden with local vault) rather than in cleartext notes or documents.

Identifying fake .onion sites: (1) Address mismatch: the .onion address does not match any verified, signed source. Never proceed without verification. (2) Requests for credentials without context: legitimate services do not ask for your account credentials without a clear login page context. (3) Unusual payment requests: a site that suddenly changes payment methods or asks for payment to an address different from previous transactions may be compromised. (4) Poor security indicators: lack of self-signed HTTPS (even if not required, legitimate privacy-conscious services often implement it), broken functionality, or unfamiliar design compared to the expected site. (5) Too-good-to-be-true offers: sites offering unusually large cryptocurrency bonuses, guaranteed returns, or other financial lures are almost certainly fraud. (6) Social pressure and urgency: 'Limited time offer', 'Account will be closed', or other pressure tactics are manipulation. Legitimate services do not create false urgency. If any of these red flags appear, close the site, generate a New Identity in Tor Browser, and verify the .onion address from scratch via trusted sources.