Dark Web Insight
privacy

How to Verify a PGP Signature Properly

A good signature from an unknown key is not proof. This walkthrough covers Tor Browser downloads, clearsigned statements, fingerprints and revocation.

By Dark Web Insight Research Desk8 min readUpdated

gpg --verify printing "Good signature" is the start of the check, not the end. That line only means: this file matches a public key you already have. It says nothing about whether that key belongs to the Tor Project, a journalist, or someone who uploaded a lookalike key last night. The PGP encryption guide covers how keys work; this page is the verification workflow people skip.

What a signature proves

A detached or clearsigned OpenPGP signature proves two things if the math checks out: the bits have not changed since they were signed, and the signer held the private key that matches the public key you used. It does not prove the human identity behind the key. It does not prove the key is the one you saw last year, unless you compare fingerprints. It does not prove the signer still controls the key if it has been revoked and you have not fetched the revocation.

Three everyday cases:

  • A software download. Tor Browser ships a package plus a .asc signature. You want to know the build is the one the Project signed, not a bundle with a clipboard stealer.
  • A clearsigned statement. A researcher or a market operator posts a signed mirror list or a canary. You want to know it is the same key as last time, not a new key with the same display name.
  • Mail or a document. Someone claims a leak or a denial. You want integrity, then a separate process for identity.

End-to-end encryption is a different property (only the recipient can read the body). Signatures are about authenticity and integrity. Markets that advertise "PGP-verified" are using the same primitive; the PGP-verified markets note is about how that claim is abused.

Step 1: Get the file and the signature from the same official channel

For Tor Browser, download the package and the matching .asc from torproject.org (or the Project's documented mirrors). Do not mix a .exe from a search ad with a signature from the official site. Filename and version must match. If a page offers "Tor Browser + crack" or a Google Drive zip, stop.

For a clearsigned message, save the exact block including the BEGIN PGP SIGNED MESSAGE header. Copy-paste from a web forum often wraps lines and breaks the signature.

Step 2: Import the signer's key from a place you already trust

gpg --import tor.keyring
# or, once you have a fingerprint you trust:
gpg --recv-keys 0xFINGERPRINT

The Tor Project publishes its signing key and fingerprint on the same official properties as the downloads. Importing a key from a random keyserver because the name field says "Tor Browser Developers" is how people verify malware. Keyservers are a distribution channel, not an identity service.

If you already have the key from last year's verify, reuse it. That is the whole point of pinning.

Step 3: Compare the fingerprint out of band

gpg --fingerprint 0xFINGERPRINT

Read the 40-hex-digit fingerprint. Compare it to a source that is not the file you just downloaded: the Project's website you typed by hand, a previous printout, a colleague's known-good copy. A single-character difference is a different key.

This is the step most walkthroughs bury. Without it you are doing trust-on-first-use: the first key you saw wins. TOFU is acceptable for a throwaway chat. It is not acceptable for a browser you will use to open unknown sites.

Classic web-of-trust signing parties are rare now. What remains is: multiple independent publications of the same fingerprint, plus a key that has a history of signatures you have checked before.

Step 4: Run the verify and read the full output

gpg --verify tor-browser-linux-x86_64-14.x.x.tar.xz.asc tor-browser-linux-x86_64-14.x.x.tar.xz

You want: Good signature, the expected primary UID, and a fingerprint you already compared. Warnings you should not ignore:

  • Good signature from a key you just imported and never pinned. The math is fine; the identity is not.
  • Expired key. The signature may still be historically valid; a current release should not be signed with a dead key without an explanation.
  • Revoked key. Stop. Fetch the revocation certificate reason if you can; do not install the binary.
  • BAD signature. The file does not match. Re-download from the official site. If it still fails, do not run the file.

Kleopatra and other GUI fronts show the same states with different wording. "Green" is not enough if the key is unknown.

Step 5: Check expiry, revocation and a second channel

Refresh the key (gpg --refresh-keys) from a keyserver after you already know the fingerprint, so you pick up revocations. Look at the creation date. A brand-new key claiming to replace a ten-year identity, announced only on a forum thread, is a classic substitution.

For high-stakes statements (a seizure canary, a signed list of mirrors), require a second channel: the same signature quoted on the operator's previous known page, or a journalist who has checked the fingerprint independently. Metadata hygiene still applies to anything you save alongside the key.

Failure modes that fool careful people

Name collision. OpenPGP UIDs are free text. Anyone can create a key named "Tor Browser Developers" or "Pharaoh". The fingerprint is the identifier.

Partial verify. Some GUIs verify a clearsigned message against any matching key on the keyring, including one you imported "just to see." Delete unknown keys after an experiment.

Wrapped downloads. An installer that contains a nested archive, plus a signature over the outer wrapper only, can carry extra files. Sign the artifact you will run.

Stale tutorials. Commands that use short 8-character key IDs are collision-prone. Use the full fingerprint.

Researchers comparing signed market announcements should treat a signature as "this is the same operator as last month," not "this operator is trustworthy." The OPSEC cases on this site are full of people who verified the wrong thing carefully.

Frequently Asked Questions

Does a good signature mean the software is safe?

It means the bits match what the holder of that private key signed. If the Project's build machine is honest and you have the Project's key, you have the official build. You do not have a guarantee the official build is bug-free.

Why do I still see a warning about an untrusted key?

GnuGUI and GnuPG mark keys as unknown until you assign ownertrust or they are certified by a key you already trust. That warning is doing its job. Assign trust only after the fingerprint check.

Can I skip PGP and compare SHA-256 hashes?

A hash from the same page as the binary is better than nothing and worse than a signature: an attacker who replaced the binary can replace the hash. A hash quoted on a second official property that you already trust is closer to a signature. Prefer OpenPGP when the Project offers it.

What if gpg is not installed?

On Windows, Gpg4win/Kleopatra is the usual path. On macOS, GPG Suite or gnupg from a package manager. On Linux, gnupg is in the default repos. The Tor Browser documentation lists the supported options; do not install a random "PGP verifier" APK.