Verifying software downloads over Tor: checksums and signatures done right
Downloading software through Tor feels safer than grabbing it from a random mirror. It is not, if you never check what actually arrived. A checksum printed next to the download link is a courtesy, not a security feature. Real verification starts somewhere else entirely.
The checksum on the same server proves nothing
If an attacker can swap an installer on a compromised server, they can just as easily replace the SHA-256 sum sitting beside it. That exact scenario played out in the 2016 Linux Mint breach, when backdoored ISO images were distributed from official infrastructure alongside checksums updated to match them, as LWN reported at the time (LWN.net). Users who dutifully compared hashes were comparing fiction. The GnuPG project admits this openly in its integrity-check documentation: comparing a hash published on the same site is less secure, because whoever modified the files would have little extra work modifying the checksums too (gnupg.org). Tor does not change the math. Exit relays cannot rewrite HTTPS traffic, but a compromised mirror, hoster or CMS can.What a signature actually proves
A cryptographic signature binds a file to one specific private key. Change a single byte after signing, and verification fails loudly. That is why the Tor Project signs every Tor Browser release with an OpenPGP key and publishes a .asc signature file next to each installer on its download page (Tor Project Support). A checksum detects corruption, and little else. A signature detects tampering by anyone who does not hold the signing key. For files travelling across onion services, third-party mirrors and exit relays, that difference is the entire ballgame.Verifying the key is the hard part
A valid signature from the wrong key is worthless. Attackers who control a distribution channel can publish forged keys as easily as forged binaries. This is where the OpenPGP web of trust earns its keep: confidence flows from fingerprints you confirmed out-of-band toward keys you have never personally met. Most users settle for convergence instead of formal webs of trust, and that is acceptable if done honestly. Cross-check the fingerprint against several independent sources: the project's documentation, keyservers like keys.openpgp.org, signed release announcements, archived mailing list posts. The GNU Project describes similar multi-source key fetching and fingerprint comparison in its security guidance (gnu.org). One source is none.Tor Browser: the worked example
Tor Browser is the right place to build the habit, because the Tor Project documents verification thoroughly. Install GnuPG first, via Gpg4win on Windows or GPGTools on macOS, then fetch the Tor Browser Developers key over Web Key Directory:gpg --auto-key-locate nodefault,wkd --locate-keys torbrowser@torproject.org Confirm the fingerprint EF6E286DDA85EA2A4BA7DE684E2C6E8793298290 against the support portal before trusting anything. Download the installer together with its .asc file, then run gpg --verify. You want a good signature from the Tor Browser Developers key; anything else means delete the file and start again. Expect one scary-looking warning along the way. A notice that the key is not certified with a trusted signature is normal and merely reflects your own trust database. What matters: - Download only from torproject.org or its official onion address.
- Verify the fingerprint against at least two independent sources.
- Re-run verification on every update, not just the first install.
- Treat any bad signature as a compromise, not a glitch.