Verify a PGP signature step by step: the complete beginner-safe procedure

a single line reading "good signature" is often the only thing standing between you and a tampered download or a forged announcement. most people either skip the check entirely or run it without understanding what it proves - and both mistakes are exploitable. this guide walks the complete path: getting a tool, importing the correct key, comparing fingerprints, running the verification, and interpreting every outcome honestly, including the warnings that trip up experienced users.

what a signature actually proves

before touching any tool, fix the definition. a valid signature over some data establishes exactly two facts: the private key corresponding to the given public key produced this signature, and the data has not changed by even one bit since that moment. it does not establish that the key belongs to the person you believe it does, nor that the signer approved the content morally or legally. those extra layers come from fingerprint comparison and from your judgment respectively.

keeping the definition sharp prevents the classic blunder: importing whatever key a website offers, seeing "good signature", and concluding safety. an attacker who controls the page supplies both a forged message and their own key, and the math happily confirms their signature. the verification chain is only as strong as its weakest human step - key acquisition.

step one: get a verification tool

1. install gnupg for command-line work: gpg4win on windows, gpg tools on macos, or the distro package on linux. confirm with gpg --version.
2. alternatively, for quick checks and learning, use our browser-based pgp verify tool. it runs entirely client-side - keys and messages never leave your machine - and returns a plain-language verdict.
3. either path implements the same openpgp standard. skills transfer completely between them.

step two: acquire the signer's public key from a trusted source

1. find the fingerprint the signer publishes on their long-lived official site, their signed prior announcements, or documentation. the fingerprint is a 40-character string like 1234 abcd ... - this is the identity anchor.
2. fetch the matching key: gpg --recv-keys <fingerprint> from a keyserver, or import an armored key file the signer distributed.
3. compare immediately. run gpg --fingerprint <email> and read the output character by character against the published fingerprint, or paste both into our fingerprint comparator for an automated verdict.
4. if the fingerprints differ at even one character, stop. you are holding an impostor key, and everything downstream would be meaningless.

step three: run the verification

the mechanics differ slightly by signature format, but the principle is identical: present the tool with both the data and the signature, let it do the math.

• detached signature (.asc next to a download): gpg --verify file.tar.gz.asc file.tar.gz - the signature file covers the download file beside it.
• clearsigned message (text wrapped between BEGIN and END PGP SIGNATURE markers): gpg --verify message.txt reads the signed block directly.
• combined sign-and-encrypt messages: decrypt first; the verification happens automatically during decryption.

in the browser tool, paste the signed block and the signer's public key into the two fields and submit. a well-formed result states the signing key's fingerprint and timestamp alongside the verdict - read the fingerprint, not just the verdict, and confirm it matches the key you intended to check against.

step four: interpret every outcome correctly

outcomes fall into four buckets, and misreading the last one causes endless beginner panic:

• "good signature" cleanly: the data is intact and was signed by that key. combined with your fingerprint comparison, the check passes fully.
• "good signature" plus a trust warning: the signature is valid; the warning only notes you have not personally certified the key in your local web of trust. this is normal and not an accusation of forgery.
• "bad signature": serious. the data changed after signing, or the wrong key was supplied. do not use the data; investigate the source.
• "no public key": mechanical, not sinister. fetch the correct key and retry.

clearsigned messages deserve special care

warrant canaries, security advisories and mailing-list statements usually arrive clearsigned, and they break for mundane reasons: email clients reflow lines, forums strip trailing whitespace, chat apps collapse newlines. cleartext signatures are sensitive to exactly such invisible changes. when a clearsigned message fails:

1. re-copy from the original source, avoiding intermediate applications.
2. run the block through our armor cleaner, which restores canonical line wrapping and reports what it fixed.
3. retry verification on the cleaned block. if it now passes, formatting damage was the culprit, not fraud.
4. only after cleaning fails should you treat the outcome as a genuine bad signature.

we apply the same skepticism when reading the warrant canaries we track - a failed canary check triggers a re-verification routine before any editorial conclusion.

combining signatures with checksums

software releases typically ship a checksums file listing sha-256 hashes, signed with the maintainer's key. the correct order matters: verify the signature over the checksums file first, then compute your download's hash and compare it against the now-trusted list. our sha-256 tool handles the hashing locally. doing it backwards - trusting a bare checksum file with no signature - verifies nothing, since an attacker replaces both files together. the full reasoning for downloads fetched over tor is covered in our dedicated guide.

mistakes that void the whole exercise

• trusting a short key id instead of the full 40-character fingerprint - short ids have been collision-spoofed in the wild.
• importing the key from the same untrusted channel that delivered the message.
• treating the signature timestamp as proof of when a document was drafted; timestamps are claimed by the signer's clock, not witnessed.
• skipping verification because "the site had https" - transport security says nothing about content authenticity at the far end.

make it muscle memory

verification is a habit, not a chore. ten seconds of fingerprint comparison and one paste-and-click verdict per important message beats weeks of explaining how a forged announcement emptied a wallet or planted a backdoored build. start with low-stakes practice until the sequence - trusted fingerprint, key import, verify, read the verdict carefully - becomes automatic, then apply it everywhere it counts.

expired and revoked keys: reading the third verdict

beyond good and bad signatures, gnu pg occasionally reports that the key is expired or revoked. neither means the signature math failed - they mean the key holder (or someone with the key) published metadata limiting the key's validity. an expired key simply passed its expiry date; many signers set two-year expiries as hygiene and extend them routinely. a revocation certificate is stronger: it says stop trusting this key, usually because it was lost or compromised.

the practical response differs. for an expired key on an otherwise healthy project, check whether a newer key or renewed expiry exists on the official site - the old signatures remain valid for the period the key was actually valid. for a revoked key, treat everything signed recently with extra suspicion and look for a signed statement explaining what happened. silence after a revocation is itself information: responsible projects announce key rotation loudly and sign the announcement with the successor key.

• expiry dates are declared by the signer in advance and can be extended; they are weak signals on their own
• revocations are deliberate kill switches and should always change your behavior
• a key you verified last year may have been replaced since - re-check fingerprints whenever a signer goes quiet and then returns

reading actual gpg output without fear

command-line verification scares beginners because the output looks like a wall of diagnostics. most of it is ignorable. when you run gpg --verify on a healthy file, the lines that matter are these three: "Signature made" followed by a timestamp, "using RSA key" followed by the short id of the signing key, and finally "Good signature from". everything else - primary key fingerprints not matching trust database warnings, missing trust values - is context, not error.

the one line to memorize is the failure form: "BAD signature". gnu pg prints it only when the mathematical check fails outright, which makes it unambiguous in a way few security tools manage. if instead you see "No public key", nothing about the data was judged at all - the tool lacked the input it needed. learning to distinguish "checked and failed" from "not checked" is most of the literacy required.

verifying a real release end to end

1. download the software archive and its detached .asc signature from the official site, plus the checksums file if one exists.
2. import the maintainer's key and confirm its fingerprint against the value published on their long-lived site - our fingerprint comparator automates the character-by-character part.
3. verify the checksums file's signature first: gpg --verify sha256sums.asc sha256sums. this is the anchor document.
4. hash your downloaded archive with our sha-256 tool and compare against the now-authenticated list.
5. optionally verify the detached signature over the archive itself as well - belt and suspenders takes seconds.
6. record the date and the key fingerprint you used; next release, you already have the anchor and the process halves in length.

that final habit - writing down which fingerprint authenticated which source, and when - is what separates people who verify once from people who have a verification practice. six months from now, when a vendor changes keys or a project rotates maintainers, your notes become the history that lets you judge whether the new state is continuity or compromise.