Verify PGP Signatures Without Fooling Yourself
The Two Questions a Signature Answers
A signature is a number computed from a file's contents and a private key. Anyone holding the matching public key can recompute the relationship and see whether it holds. Change one byte of the file and it stops holding, which is why a signature detects tampering, truncated downloads and corrupted transfers with equal reliability. What it cannot do is tell you whose key you just used. Suppose an attacker replaces both an installer and its signature file on a compromised mirror, signing the malicious build with a key they generated that morning under the name Tor Browser Developers. Your verification tool reports a perfectly valid signature, because it is valid. It says nothing about identity, and identity was the whole point. That is why every serious verification workflow has a fingerprint step. A fingerprint is a 40-character hexadecimal summary of a public key, and the developer publishes it somewhere you can reach independently of the download page. Comparing what your keyring holds against what the project publishes is the part that resists a hostile mirror. Treat display names as decoration. Names, comments and email addresses inside a key are typed by whoever created it and are not verified by anything. Two keys claiming the same email are trivially easy to produce; two keys sharing a fingerprint are not.
Installing the Tools on Each Platform
On Linux you almost certainly already have what you need. Run gpg --version at a terminal; most distributions ship GnuPG by default, and Debian or Ubuntu users can install it with apt install gnupg if it is missing. Fedora uses dnf install gnupg2. On macOS the shortest path is Homebrew: brew install gnupg gives you the same command-line tool. GPG Suite offers a graphical alternative with Finder integration, which some people find easier for occasional checks. Either works, and both use the same underlying engine. On Windows, Gpg4win bundles GnuPG with Kleopatra, a certificate manager that handles verification through dialogs rather than commands. After installing, you can right-click a signature file in Explorer and choose the verify option. If you prefer the terminal, the same installer puts gpg on your PATH for use from PowerShell or Command Prompt. One detail catches newcomers. Download the tool from its own project site, not from a software aggregator that wraps installers in bundleware, since a compromised verification tool defeats the entire exercise before you begin. Confirm the version once installed, and note that GnuPG 2.2 and later behave slightly differently from the long-obsolete 1.4 series in how they present trust warnings, which matters when you compare your output against an older tutorial.
Verify a PGP Signature Step by Step
Take Tor Browser as the worked example. Download the installer and, from the same official page, the small file beside it ending in .asc, which is the detached signature. Keep both in one folder and do not rename either, because the tool matches them by name. Next, get the signing key into your keyring. The Tor Project documents the current signing identity and the command to fetch it, typically retrieving it from a keyserver by fingerprint. Fetching by fingerprint rather than by name matters, since a keyserver will happily hand over any key that anyone uploaded under a given email address. Now compare fingerprints. Run gpg --fingerprint followed by the key identifier and read the 40 characters against what the project publishes in its documentation. Check the whole string, not the last eight characters, because short identifiers can be deliberately duplicated. Finally run the verification itself: gpg --verify followed by the name of the signature file. GnuPG locates the matching installer automatically and prints its verdict. Read the output before doing anything else, and specifically before running the installer. Once malicious code executes, a later check is archaeology rather than defense. If anything looks unexpected, delete both files and start again from the official page rather than trying to patch around the problem.
Reading GnuPG Output Line by Line
The tool prints several distinct verdicts and they mean different things. Good signature from followed by the key's name is the outcome you want, and it means the file matches. Read the name and the key identifier on that line rather than stopping at the word good. BAD signature means the arithmetic failed. Either the file changed after signing or the signature belongs to a different file. Corrupted or interrupted downloads produce this constantly, so re-download once before assuming malice, but never install the file you already have. The confusing one is the block beginning WARNING: This key is not certified with a trusted signature, usually followed by a line about no indication that the signature belongs to the owner. This is not a failure. GnuPG is saying the mathematics checked out but you have not personally marked the key as trusted in your local web of trust. When you have compared the fingerprint against the project's published value, this warning is expected and harmless. Can't check signature: No public key means exactly what it says: import the key first. And gpg: no valid OpenPGP data found usually means you fed it the wrong file, often the installer instead of the .asc, or a signature that arrived as HTML because a browser saved a webpage rather than the file.
Signatures, Hashes and What Each One Proves
Projects often publish both a signature and a SHA-256 hash, and the two answer different questions. A hash is a fingerprint of file contents with no key involved. Compute it locally with sha256sum on Linux, shasum -a 256 on macOS, or Get-FileHash in PowerShell, then compare it against the published value character by character. That comparison catches corruption reliably. Against a determined attacker it depends entirely on where the expected hash came from. If someone controls the page serving the download, they control the hash printed beside it, and both will agree perfectly while the file is malicious. The check confirms two attacker-supplied values match each other. A signature closes that gap because forging one requires the developer's private key, not merely control of a web page. This is why signed checksum files exist as a middle path: a text file listing hashes for several builds, itself signed, letting you verify one signature and then hash-check any file in the list. There is a practical division of labor here. Use a hash for a quick integrity check after a flaky download over hotel wifi. Use a signature plus a fingerprint comparison when the question is whether the publisher really produced this build. Describing both as verified in the same breath is how people end up trusting the weaker of the two.
Key Rotation, Expiry and Ongoing Habits
Keys do not last forever. Developers set expiry dates deliberately, so a key that verified fine last year may now print an expiry notice. That message is informational about the key rather than a claim that the file was altered, though it is a signal to check whether the project has published a successor. Legitimate rotations are announced and, when done properly, the new key is signed by the old one so the transition itself is verifiable. An unannounced new key appearing only on a download page deserves suspicion. Compare against the project's documentation, reached through your own bookmark, before importing anything. Revocation is the other case worth recognizing. If a private key leaks, the owner publishes a revocation certificate, and GnuPG will tell you the key has been revoked. Signatures made after a compromise cannot be trusted, and the tool has no way to know which side of that line a given signature falls on, so treat a revoked key as a stop sign. Build two habits and the rest follows. Refresh keys occasionally so your keyring learns about expiry and revocation instead of running on stale data, and keep a short private note of the fingerprints you have confirmed, along with where and when you confirmed them. That note is what lets you notice a substitution rather than accept whatever a page shows you today.
Sources and official tools
Official references checked when this guide was written. Product links contain no affiliate tracking.
Frequently asked questions
Why does GnuPG warn about an untrusted key after a good signature?
Because trust and validity are separate. The signature checked out mathematically, but you have not marked that key as trusted locally. Once you have compared the fingerprint against the project's published value, the warning is expected.
Is checking the short key ID good enough?
No. Short identifiers of eight or sixteen characters can be deliberately duplicated by generating keys until one collides. Compare the full 40-character fingerprint against what the developer publishes.
What should I do if the signature comes back BAD?
Do not run the file. Re-download both the installer and its signature from the official page, since interrupted transfers cause this frequently. If a clean download still fails, stop and treat the mirror as untrustworthy.
Does a valid signature mean the software is safe?
It means the publisher produced that exact build. It says nothing about bugs, vulnerabilities or whether the developer's own systems were compromised before signing. Authenticity and safety are different properties.