Short answer: OpenPGP (usually via GnuPG) answers two questions: “was this file or text signed by the key I already trust?” and “can only the holder of this public key read this message?” It does not hide who talks to whom, and it does not survive a stolen private key. For Tor users the high-value jobs are verifying software and checking operator-signed address lists — not encrypting shopping chat.
This is not a marketplace 2FA walkthrough and not a substitute for the Tor Project’s signature page. Tool comparison: privacy tools. Glossary: PGP, canary statement.
Two operations, one failure mode
Encrypt with the recipient’s public key; only the matching private key decrypts. Sign with your private key; anyone with the public key can check that those exact bytes were signed.
OpenPGP typically wraps a one-time symmetric key inside public-key encryption (hybrid encryption). The math is the easy part. The hard part, in every Tor-related scam that uses “we signed it,” is binding a key to an identity:
- A fingerprint copied from the same HTML as the onion it is meant to bless proves nothing.
- A “Good signature” over a phishing URL is a valid signature of a lie.
- An online “paste your key and message” checker is a third party who now has the text and, if you were careless, more.
EFF’s Surveillance Self-Defense material still uses PGP as a teaching example of public-key encryption while noting that everyday private chat has moved to apps with fewer manual steps. In the Tor ecosystem the manual steps remain, because canaries and package signatures are files, not a chat ratchet.
Job 1: Tor Browser packages
Desktop Tor Browser builds on torproject.org ship with a matching .asc OpenPGP signature. Verification means: you imported the Tor Browser Developers key, you confirmed its full fingerprint against a source that is not the download mirror you are testing, and gpgv (or the documented equivalent) reports a good signature over this installer.
The Project documents the key as:
EF6E 286D DA85 EA2A 4BA7 DE68 4E2C 6E87 9329 8290
associated with torbrowser@torproject.org. Import via their documented Web Key Directory command, or the fallback they publish. Then compare that fingerprint to paper, an older known-good machine, or another official Project page — not only to the blog post that sat next to the .exe.
A dated signature is normal: each new build gets a new .asc. The date changing is not a failure. A bad signature, a missing .asc on a random “mirror,” or an installer with no signature at all is a stop.
Windows users typically install Gpg4win and run the commands in cmd. macOS users use GPG Suite / GPG Tools. Linux usually already has GnuPG. Exact command lines belong on the official how-to so they do not drift here.
Android: prefer the official store channel named in the setup guide. An APK from a forum is the same class of problem as a portable Windows bundle.
Job 2: operator-signed lists and canaries
Newsrooms, privacy services, and some onion operators publish a dated, signed statement: current hostnames, sometimes a warrant canary (“as of this date, no secret order”). The signature shows that the private key still produced a message. It does not prove the operator is kind, solvent, or uncompromised.
Treat a canary as a heartbeat with known failure modes:
- Compelled continued signing is a documented theoretical limit.
- A skipped update is often neglect.
- Scope is whatever the text actually says — not “the whole organization is clean.”
See warrant canary. Combine a live canary with full-address checks, not instead of them.
Public indexes describe the same culture. onion.live says some listings carry PGP-signed mirrors and that it probes uptime; FORT is their HTML convention for embedding a fingerprint and a signed hostname list. torwiki.org treats signed canaries as how operators re-authenticate after a move. Those are process claims. They do not bind a key for you. Catalog tags such as “PGP” on a market card: onion directories.
Job 3: encrypting a message over Tor
Tor hides connection metadata from the destination; it does not encrypt the body of an email that later sits on a mail server. PGP encrypts the body (and, depending on the tool, attachments). Headers — from, to, subject in ordinary mail — still leak. That is why PGP is a content control and Tor is a path control. They stack; neither replaces OPSEC.
If you generate a key:
- Use current GnuPG defaults unless you have a written reason not to.
- Protect the private key with a passphrase you will not reuse as a site password.
- Keep a revocation certificate offline.
- Publish the fingerprint through a channel that already exists (personal site you control, a key you have used for years), not first on the forum where you just introduced yourself.
Do not upload private keys to “PGP web tools.” Decrypt locally.
What “Good signature” does not mean
| You saw | It means | It does not mean |
|---|---|---|
| Good signature | These bytes match this key | The operator is legitimate |
| Matching fingerprint on the same page as the onion | The clone is self-consistent | Independent identity |
| Fresh canary | Someone with the key signed a date | No raid, no exit, no phishing mirror |
| Encrypted mail | Body is unreadable in transit (if used correctly) | Metadata is hidden; device is clean |
Common mistakes
Skipping verification because the download “came from HTTPS.” HTTPS authenticates a site. Phishing sites have certificates too. The signature binds the file to the Project key.
Using a different key because a blog said “our Tor key.” There is one documented Tor Browser Developers signing key for packages; look-alike UIDs are the attack.
Encrypting to a key you just imported from the person who asked you to encrypt. That is a closed loop. Out-of-band fingerprint comparison is the whole point.
Assuming PGP 2FA on a shop (a password plus a signed challenge) authenticates the site. It authenticates that you hold a key the account registered. A clone that stole the database can still accept the same dance. Address verification comes first.
A minimal practice list
- Verify Tor Browser with GnuPG per the Project page; store the fingerprint offline.
- For any onion you would log into, demand a signature over that exact hostname from a key whose fingerprint you did not first meet on that hostname.
- Keep signed texts as files; verify with local GnuPG.
- Separate roles: a key used to sign research notes is not the key you generated in a hurry for a throwaway account.
- If this feels heavy, that is correct — it is why bookmarks plus a small set of known keys beat a new directory every session.
Sources
- Tor Project: How to verify Tor Browser’s signature
- EFF SSD: How public-key encryption systems work
- EFF SSD: How to use PGP for Linux
- GnuPG: GnuPG
- onion.live: About (PGP-on-listing and uptime claims)
- TorWiki: editorial notes on PGP canaries as announcement authentication (paraphrased)