Verification Guide

How to Verify Onion Addresses

An onion address is only as trustworthy as the source it came from. Cryptographic verification is the single most reliable defence against phishing clones, substituted links, and impersonation on anonymous networks.


Why Verification Matters

Version 3 onion addresses are 56 characters long and are derived directly from a service's public key. They are not chosen by a human and they are not memorable; to the eye, one valid address looks much like any other. This property, which is essential to the security model of onion services, is also what makes them difficult to verify by inspection. A reader cannot tell whether an address is genuine simply by looking at it, in the way one might notice a misspelled domain name on the conventional web.

Attackers exploit this gap. A common technique is to generate a large number of onion keys until one produces an address whose first several characters match a well-known service, then publish the lookalike on forums, in search engine results, in wikis, or in unsolicited messages. Another technique does not involve lookalike addresses at all: the attacker simply replaces the link on a page they control, or on a page whose content they can edit, with an address that routes to a proxy they operate. Users who copy the address from that page reach a site that is visually identical to the original.

The consequences of connecting to a cloned service are serious. Credentials entered into a phishing copy are captured and reused. Funds sent to addresses displayed by a proxied site are diverted. Messages, uploads, and account details pass through infrastructure the attacker controls, which may be enough to link an otherwise anonymous user to an identity. Because the connection itself is still routed through the anonymity network, none of the usual warning signs, such as certificate errors, appear.

Never trust an onion address because it appeared in a search result, a forum post, or a message. Obtain it from a source that is cryptographically signed by a key you have already verified, and check the signature before you connect.

PGP Verification Guide

Operators of well-run onion services publish their addresses in a file signed with an OpenPGP key. Verifying that signature proves two things: that the file was produced by the holder of the key, and that it has not been altered since. The procedure below uses GnuPG, the reference implementation of the OpenPGP standard, but any compliant client follows the same steps.

  1. Import the official PGP public key. Obtain the operator's public key from a source you already trust, such as a key that has been published for a long time and referenced consistently across independent locations. Import it with gpg --import key.asc, then display its fingerprint with gpg --fingerprint. Compare the full 40-character fingerprint, not just the short key ID, against the fingerprint published by the trusted source. Short key IDs can be forged; full fingerprints cannot be practically collided.
  2. Download the signed mirror or address list. Fetch both the list itself (for example mirrors.txt) and its detached signature (mirrors.txt.asc). A detached signature is a separate file that covers the exact bytes of the original. Some operators instead distribute a clearsigned message, where the text and the signature are contained in a single .asc file; the verification step is the same.
  3. Verify the signature with GnuPG. Run gpg --verify mirrors.txt.asc mirrors.txt for a detached signature, or gpg --verify message.asc for a clearsigned file. GnuPG must report Good signature together with the fingerprint of the key you imported in step one. A warning that the key is not certified with a trusted signature is expected if you have not marked the key as trusted locally; it does not indicate a problem so long as the fingerprint matches. A BAD signature result, or a signature from an unknown key, means the file must not be used.
  4. Compare the onion address character by character. Open the verified file and compare the address it contains against the address you intend to visit. Check the entire 56-character string, not only the beginning and end, since lookalike addresses are generated to match the visible prefix. Copying the address directly from the verified file into Tor Browser eliminates transcription errors.
  5. Only proceed with a verified match. If every step succeeds, the address is authentic. If any step fails, for example a fingerprint mismatch, a bad signature, or an address that differs from the one you were given, stop and treat the address you were given as hostile. Do not attempt to resolve the discrepancy by connecting to the site.

Red Flags

Most phishing attempts on onion services share a small number of recognisable patterns. The table below lists the most common warning signs, what each one typically indicates, and the appropriate response.

Warning Sign What It Means Action
Address received via unsolicited message Legitimate operators do not push their addresses to individuals. Direct messages and emails are the primary distribution channel for phishing links. Discard the message. Obtain the address from the operator's signed list instead.
Slightly different characters in the address A vanity address generated to match the first few characters of the genuine one. The remainder of the string differs. Compare all 56 characters against the verified list. Do not connect if any character differs.
No PGP signature provided The source offers no cryptographic proof of origin. Anyone could have written or edited the page. Treat the address as unverified. Locate a signed list before proceeding.
Signature fails to verify or reports BAD signature The file was modified after signing, or the signature was produced by a key other than the one you imported. Do not use the file. Re-download from the original source and re-verify; if it still fails, assume tampering.
Site asks for personal information or a PGP private key No legitimate service needs your private key. Requests for identifying details beyond what the service requires indicate a credential-harvesting clone. Close the site immediately. Never upload or paste a private key anywhere.
Link only found in search engine results Search indexes for onion services are routinely seeded with phishing addresses and are not curated for authenticity. Use search results only as a starting point. Verify the address through a signed source before visiting.
Login page appears before the expected landing page Proxied clones often intercept the login step so that credentials can be captured before traffic is forwarded. Do not enter credentials. Confirm the address against the verified list, then reconnect.

Tools for Verification

The following free and open-source tools cover every step of the verification process, from importing keys to inspecting a service once its address has been confirmed.

GnuPG

The reference implementation of the OpenPGP standard. GnuPG imports public keys, displays fingerprints, and verifies detached and clearsigned signatures from the command line. It is the tool used in the guide above and is available on every major operating system.

gnupg.org

Tor Browser

The official browser for reaching onion services. It resolves and validates the cryptographic structure of version 3 addresses and displays the full address in the URL bar, which allows a final character-by-character comparison before any data is submitted.

torproject.org

OnionScan

An open-source auditing tool that inspects an onion service for configuration errors and information leaks. After an address has been verified, OnionScan can reveal whether the service exposes server details or metadata that suggest a hastily assembled clone.

github.com/s-rah/onionscan

Kleopatra

A graphical certificate manager for OpenPGP developed by KDE and bundled with Gpg4win. Kleopatra wraps GnuPG in a desktop interface for importing keys, checking fingerprints, and verifying signed files without using the terminal.

apps.kde.org/kleopatra