How to Check a PGP Signature in 2026, and What It Proves

What a PGP signature does and does not say, per torverify

Verifying a signature answers two things: was this signed by the key I hold, and is it unaltered since it was signed. Both yes means the content is authentic to that key, byte for byte. What a valid signature cannot tell you, on its own, is whether the key really belongs to who you think it does. A stranger can generate a keypair and sign a file with it all day, and the signature will verify perfectly — against the wrong key. That is exactly why torverify treats a signature check as step one of two, never the whole answer, and why the fingerprint cross-check below is not an optional extra.

Signed does not mean "from torverify"

A message signed by some key is a much weaker claim than a message signed by the key torverify actually uses. Anyone can wrap a phishing announcement in a valid-looking signature block from a key they generated five minutes ago. The signature will pass a naive check. It will fail the moment you compare its fingerprint against the one torverify publishes across more than one independent channel — which is the entire reason that second step exists in this guide and in torverify's own methodology.

What "unaltered" actually covers

The unaltered guarantee is narrower than it sounds. It means the exact bytes you are checking match the exact bytes that were signed — not that the content was true when it was written, not that it is still current, and not that the signer had good intentions. A signed lie is still a validly signed message. torverify's own signed source of record is designed around this limit: the signature proves the entry has not been tampered with in transit, and the 2-of-3 quorum described on the methodology page is what does the work of establishing that the entry was correct in the first place.

The steps torverify recommends for every signature check

1. Get the public key. Obtain the signer key and fingerprint through a channel you trust, ideally more than one, before you look at any message it supposedly signed.
2. Load the key and message. Paste both into a verifier that runs locally, such as torverify's own browser PGP tool, so nothing is uploaded anywhere.
3. Read the result. A valid result means the key signed it and it was not altered — nothing more, nothing less.
4. Match the fingerprint. Compare the signer fingerprint against a second copy, obtained separately, before you rely on any of it.

Common mistakes torverify sees when checking a PGP signature

Most signature-check failures on this kind of reference are not cryptography failures — the math either verifies or it doesn't. They are process failures: skipping a step, trusting the wrong source for a key, or misreading what a green checkmark actually covers. torverify sees the same handful of mistakes come up again and again, so they are worth naming explicitly.

Mistake 1: trusting the key that ships with the message

If a message arrives bundled with "here is the key that signed this," and you import that exact key to verify it, the check will always pass — even against a forged message, because you supplied the attacker's own key as the trusted key. The public key has to come from a source independent of the message it is verifying, ideally one you fetched before you ever saw the message in question.

Mistake 2: skipping the fingerprint cross-check

This is the single most common shortcut, and the one that defeats the entire point of signing. A "Good signature" result from your PGP tool only tells you the message matches a key. It says nothing about whose key that is unless you separately compare the fingerprint against a copy obtained elsewhere — a second torverify channel, a prior confirmed copy, anything that was not handed to you alongside the message itself.

Mistake 3: verifying on a site that "sends" you the result

Any verifier that requires uploading your key or message to a remote server to get an answer back is asking you to trust that server's honesty on top of the cryptography. torverify's PGP tool runs the check entirely in your own browser for exactly this reason — there is nothing to intercept, log, or lie about on the way back.

Mistake 4: treating an expired or revoked key as still good

A signature can verify cleanly against a key that has since been revoked or has expired, depending on which tool you use and how it is configured. Always check the key's own status, not just whether the signature math checks out, before treating a result as current.

torverify worked example: verifying a signed announcement

The steps above are easy to describe abstractly and easy to rush in practice. Here is what actually happens, slowly, when a real signed message is checked against torverify's own published key — the same process the site recommends for any project's signed entry.

Step 1 — obtaining the public key first, separately

Before opening the signed message, fetch torverify's public key and its fingerprint from the PGP page, and note the fingerprint down somewhere outside the browser tab you are about to use. This ordering matters: getting the key first, independent of the message, is what makes the later comparison meaningful instead of circular.

Step 2 — pasting the message and key into a local verifier

Open torverify's browser-based PGP tool, paste the armored public key into the key field and the signed message into the message field. Nothing leaves the browser at this point — the verification math runs client-side, which is checkable by anyone willing to read the page's source.

Step 3 — reading "Good signature" versus a failure

A successful check reports a valid signature tied to the key's fingerprint. A failed check reports exactly why: a mismatched hash means the content changed after signing, an unknown key means the signature was made with something other than the key you loaded. Either failure is a hard stop, not a maybe.

Step 4 — the fingerprint cross-check that actually matters

Finally, compare the fingerprint your tool displayed against the one you noted down in step 1, and ideally against a second independent channel as well. Only once both the signature and the fingerprint agree does this example count as fully verified — a green "valid signature" light by itself is only half the job.

Do it now

Open torverify's PGP tool, paste a public key and a signed message, and watch the check run without anything leaving your browser. Then compare the fingerprint it shows against the copy on torverify's signer keys list and a second channel before you treat anything as confirmed.

torverify's browser tool versus desktop GnuPG, in practice

Both approaches implement the same OpenPGP standard and arrive at the same yes-or-no answer on a given signature. The choice between them is about workflow, not about which one to trust more.

When the browser tool is the right call

For a single, occasional check — confirming one signed announcement, one signed mirror update — torverify's browser tool asks nothing of you beyond pasting two blocks of text. No install, no keyring to manage, no configuration. That is precisely the case this guide is written for.

When desktop GnuPG earns the extra setup

If you are managing a keyring of your own, signing your own messages, or working from an air-gapped machine, a desktop client such as GnuPG is the better tool for the job. It is also the reference implementation the OpenPGP standard is measured against, which makes it worth having installed regardless of which tool you reach for on a given day.

The hard part isn't the check — it's getting the right key

Every step on this page assumes you already hold the correct public key. That assumption is doing almost all of the work, and it is where verification most often quietly breaks. The cryptography is the easy, mechanical part; obtaining a key you can actually trust is the judgment call.

A keyserver is a convenience, not an authority

Fetching a key with gpg --recv-keys from a public keyserver is convenient, but a keyserver does not vouch for anyone — historically, anyone could upload a key under any name, so the fact that a key is "on the keyserver" proves nothing about who controls it. A keyserver is a fine way to obtain a key and a useless way to trust one. Whatever you pull down still has to have its fingerprint confirmed against an independent source before it means anything.

Why "independent channels" has to mean genuinely independent

The whole strength of a fingerprint cross-check comes from the channels being controlled by different parties, so that compromising one does not compromise the comparison. Two copies of a fingerprint that both trace back to the same website, or the same account, are not two channels — they are one channel counted twice, and an attacker who owns that source can make both agree. A real second channel is something an attacker would have to compromise separately: a different site under different control, a copy you recorded yourself weeks earlier, a fingerprint a trusted contact read to you directly. torverify publishes its signer fingerprints across more than one independent channel for exactly this reason, and its methodology describes how those channels are kept apart.

First-contact is the unavoidable weak point — and how to shrink it

The first time you ever encounter a signer you have no prior copy to compare against, so the very first fingerprint you record is taken partly on trust. This is a genuine limitation of any signature system, torverify's included, and pretending otherwise would be dishonest. You cannot eliminate first-contact risk, but you can shrink it: gather the fingerprint from as many independent places as you can on that first encounter, write down the full 40-character value rather than a short key ID, and treat every later check as confirmation that nothing has changed since. Once you have a trusted first copy, every subsequent verification is strong; the care belongs at the beginning.

The same check on the command line, step by step

The browser tool and desktop GnuPG reach the identical yes-or-no answer, but if you already have GnuPG installed it is worth knowing the exact commands, because the command line shows you a little more of what is happening and leaves an auditable trail. Everything below runs locally; nothing is uploaded. The examples assume a signer's public key and a signed file in the current directory.

1. Import the signer's public key. From a key file you obtained independently: gpg --import signer-key.asc. GnuPG prints the key ID and user ID it just imported — read them, do not assume.
2. Print and record the full fingerprint. gpg --fingerprint 0xKEYID shows the 40-hex-character fingerprint in ten groups of four. This is the value you will cross-check out of band; a short 8- or 16-character "key ID" is not enough, because those can be deliberately collided.
3. Verify a detached signature. For a file plus its separate .asc or .sig: gpg --verify mirrors.json.asc mirrors.json. The first argument is the signature, the second is the file it covers — getting them backwards is a common cause of confusing errors.
4. Or verify a clearsigned message. When the signature is wrapped around the text itself: gpg --verify announcement.asc with no second argument.
5. Match the fingerprint against a second channel. Compare the fingerprint GnuPG reports against a copy obtained separately — a different site, a prior confirmed note, torverify's signer keys list. Equal fingerprints, and only then, close the loop.

Reading GnuPG's output honestly

A pass prints a line beginning Good signature from followed by the user ID, and a machine-readable run — gpg --verify --status-fd 1 … — emits GOODSIG and VALIDSIG tokens you can grep for in a script. What trips people up is the warning that usually appears directly underneath: WARNING: This key is not certified with a trusted signature. That warning is expected and is not a failure. It only means you have not personally signed the key inside your own GnuPG web of trust — it says nothing about whether the signature on the file is good. The signature validity and the trust level are two separate lines reporting two separate things, and conflating them is the command-line version of the same mistake covered above: mistaking "signed by some key" for "signed by the right key." The line that actually decides it is the fingerprint, which is why the cross-check in step 5 is the real finish, not the green "Good signature" text.

What a genuine failure looks like

A tampered or wrong file prints BAD signature from — the bytes do not match what was signed, full stop, and there is no benign reading of it. A message signed by a key you have not imported prints Can't check signature: No public key, which is not a pass and not a fail but an incomplete check: you are missing the very thing you need to verify against, and importing whatever key the message conveniently travels with would defeat the point, per the first mistake on this page. Treat both a BAD signature and an unresolvable No public key as hard stops, exactly as torverify does internally.

Why torverify layers a quorum on top of a single signature check

A signature check, done correctly with a fingerprint cross-check, is already a strong guarantee for a single message. torverify's source of record adds a further layer on top: no single signature, however correctly verified, is sufficient to mark an address LEGIT.

What a single valid signature still can't rule out

A perfectly valid, correctly cross-checked signature from torverify's own key still traces back to a single point of control — if that one key were ever compromised or its holder coerced, a technically valid signature could carry a false entry. This torverify guide's steps protect you from an attacker without the key. The 2-of-3 quorum described on torverify's methodology page is what protects the system from an attacker who somehow gets one key anyway.

Two independent problems, two independent defenses

The signature check in this guide defends against forgery by someone who never held a real key. The quorum defends against a single point of compromise inside torverify's own operation. Neither substitutes for the other, and understanding both is what makes torverify's overall trust model make sense rather than looking like unnecessary duplication.