How can PGP/GPG be used to verify an .onion site's authenticity?
Executive summary
PGP/GPG is widely recommended as the reliable method to confirm a .onion site's authenticity: operators publish a PGP-signed text (commonly /pgp.txt or /mirrors.txt) containing the site's current onion addresses and mirrors, and users verify that signed message with the operator's public key to ensure the address is genuine [1] [2] [3]. Guides across darknet resources give the same high-level workflow: obtain a trusted PGP public key, fetch the signed address list, and verify the signature before trusting an .onion URL [4] [3].
1. How PGP verification is supposed to stop phishing proxies
Darknet guides explain the core threat: phishing proxies present realistic copies of a site while serving a fake onion address; because they forward real interactions, things like logins and 2FA still “work” for victims unless the onion address itself is validated. A PGP-signed mirrors file lists official onion addresses and, when verified with the operator’s public key, proves that the address was published by the legitimate operator rather than the proxy [1] [3]. Multiple tutorials explicitly instruct users to compare the address they are visiting to the ones inside a signed mirrors/pgp file and to require a “good signature” from the known key before proceeding [2] [4].
2. Practical step‑by‑step summary from consensus documentation
Recommended steps repeated across sources are: [5] obtain the site operator’s PGP public key from a trusted third party (subreddit, archivist like DarkNetLive, or an independent key repository); [6] import that key into your GPG tool; [7] open the onion address and fetch /mirrors.txt or /pgp.txt (sites often place signed proofs there); [8] run GPG to verify the signed message and confirm it returns a “good signature”; [9] ensure the onion you have in your browser is one of the addresses listed in the verified message [3] [2] [4]. Sources stress always getting the key from more than one trusted place to avoid key substitution [2] [3].
3. Where operators publish proofs and what the files look like
Multiple guides show the same format: a cleartext PGP-signed message (BEGIN PGP SIGNED MESSAGE) containing one or more .onion addresses, followed by the PGP signature block. The mirrors.txt pattern is common and explicitly shown in instructive examples, demonstrating where users should look and what a verified output looks like [3] [1]. Community-maintained lists and indexes often insist links are PGP-verified before publishing them [10] [11].
4. Key distribution — the weakest link and best practices
Authors repeatedly warn that importing the wrong public key defeats verification: you must get the operator’s public key from independent, reputable third parties (e.g., darknet news/aggregator sites, Dread, pgp.fail clones), and cross-check it across sources before trusting it [2] [3]. Guides explicitly advise comparing keys between at least two trusted places because a single compromised repository could publish a fake key [2].
5. Variations, edge cases, and alternative proofs
Not all projects publish a signed mirrors file. For example, some software projects embed the onion address inside signed release artifacts rather than offering a direct pgp.txt/mirrors.txt endpoint; in that case, you can verify the signed release and check the address inside the release notes (example: Wasabi Wallet discussion noting addresses can be verified via signed releases) [12]. Project-specific workflows exist and the general rule is the same: find a signed statement that contains the onion and verify it with an authentic key [12] [13].
6. What verification does — and doesn’t — guarantee
When correctly performed, PGP verification guarantees only that the operator who controls the private key published the onion address in that signed statement; it does not guarantee the site’s content is safe or that third-party mirrors remain uncompromised. Community lists that label links “PGP verified” still caution users that verification doesn’t equal safety or endorsement [11]. Guides therefore pair verification steps with other safety advice (use Tor Browser, avoid pasting addresses from untrusted sources) [10] [14].
7. Practical barriers for users and recommended mitigations
Several guides acknowledge friction: novices may not know how to import keys, run GPG, or locate trustworthy key sources. Tutorials and aggregated services (Dark.fail’s PGP tool, curated GitHub lists, or centralized mirror hubs) exist to simplify verification, but they themselves must be treated as additional trust anchors and cross‑checked [1] [11]. Best-practice mitigation: cross-verify operator keys across at least two independent, reputable locations and prefer automation tools from projects you trust, while understanding that such tools shift — not eliminate — trust assumptions [1] [2].
Conclusion — available sources conclude that PGP/GPG verification of signed proofs (mirrors.txt/pgp.txt or signed releases) is the standard, practical technique to confirm an .onion address’ authenticity; success depends on obtaining the correct public key from trustworthy, multiple sources and verifying the signature before trusting an address in your browser [3] [2] [1].