How to verify PGP signatures step by step: import, check, and spot fakes
A single line reading "Good signature" can be the only thing standing between you and a tampered download. Most users skip the check entirely, or worse, run it without understanding what it actually proves. This tutorial walks the full path: installing a tool, importing keys, verifying signatures, and reading failures correctly.
Start with a local install
Everything begins with GnuPG, the open-source implementation of OpenPGP. Windows users can grab Gpg4win, macOS users have GPGTools, and most Linux distributions ship gpg preinstalled. The Tor Project's support docs walk through precisely this setup for validating browser downloads (Tor Project Support). Open a terminal and rungpg --version to confirm the install works. That same command line covers every step below. No accounts, no uploads, and no trust delegated to anyone else's machine. Import the key, then verify it
A signature is only as trustworthy as the key behind it. Fetch the signer's public key withgpg --recv-keys <fingerprint>, then compare the fingerprint against a copy published on the project's HTTPS site. Riseup's OpenPGP best practices warn that anyone can upload a key to any keyserver, so blind imports remain the classic rookie mistake (Riseup.net). The fingerprint is the identity. Everything else is decoration. Verify a detached signature
Most software releases ship with a detached .asc signature file sitting next to the download itself. Put both files in one folder and rungpg --verify file.tar.gz.asc file.tar.gz. The GNU Privacy Handbook shows the expected output: a signature timestamp, the key used, and the phrase "Good signature from" (GNU Privacy Handbook). A good result proves the bytes match exactly what the key holder signed at that moment. It says nothing about whether that key truly belongs to the person or project you have in mind. That gap is closed by fingerprint comparison, never by the verification command alone. Clearsigned messages need care
Warrant canaries, security advisories, and mailing list posts often arrive as clearsigned text wrapped between BEGIN and END markers. Check these withgpg --verify message.txt, letting gpg read the signed block directly. GnuPG's manual cautions that cleartext signatures alter end-of-line whitespace handling and only cover content inside the markers (GnuPG manual). Pasting through email clients or forums can introduce trailing spaces or reflowed lines, breaking verification even when nobody touched the content. If a clearsigned message fails, test the original attachment before suspecting fraud. We apply the same caution in our coverage of warrant canaries. Read failures honestly
"No public key" means exactly what it says: fetch the right key and retry. A hard "BAD signature" is serious, because the data changed after signing or the wrong key was supplied. The most misunderstood output is "Good signature" paired with a warning that the key is not certified. That warning merely notes you have not personally marked the key as trusted. It is not an accusation of forgery. Conflating the two sends plenty of beginners chasing imaginary attackers.Mistakes worth avoiding
Four habits cause most failed or meaningless verifications we see:- Trusting a short key ID instead of the full 40-character fingerprint.
- Checking a checksum file while skipping the signature over the checksum.
- Pasting confidential keys or messages into unvetted web pages.
- Treating the signature timestamp as proof of when a document was drafted.