How to Verify a PGP Signature in Your Browser with torverify (2026)

torverify's signer keys

Everything torverify publishes, the source of record, canary notices, and verdict updates, is meant to be signed with the quorum keys below. Match these fingerprints against a copy you obtained through a second channel before you rely on them.

Why three keys instead of one

A single signer key is a single point of failure — one compromised laptop or one coerced operator and an attacker can sign anything they want in torverify's name. Splitting signing authority across three independent offline keys means at least two would have to be compromised simultaneously for a forged entry to pass the quorum, which is a categorically harder attack to pull off quietly.

What "placeholder" means for the fingerprints below

torverify would rather ship this torverify page with an honest placeholder than a fabricated fingerprint dressed up to look final. The three rows below are not live keys yet; treat anything checked against them today as unconfirmed, and check back once the quorum is published in full.

Reading the result from torverify's PGP tool

A green result means two facts held at once: the message carries a signature from the key you pasted, and nothing in it changed after signing. A red result means one of those failed, so the content was altered or a different key produced it. Either way, torverify's tool reports the signer fingerprint it found. Compare that fingerprint yourself. A perfectly valid signature from a key you have never seen tells you the file is internally consistent, not that it came from torverify or anyone in particular.

What a green result does not tell you

A VALID result confirms internal consistency between the key and the message — nothing about whose key it is. That gap is exactly why torverify's own result text always ends with a reminder to match the fingerprint against something you already trust, rather than treating "valid" and "trustworthy" as the same word.

What an error usually means

If the check throws an error instead, the usual cause is a truncated block. A public key must start at the BEGIN line and end at the END line, and a signed message needs its full armor intact. Copy the whole block, blank lines and all, and run it again. Nothing you paste is stored between attempts, and a failed attempt leaves no trace to clean up.

Common mistakes when using a browser PGP tool

The tool itself does the cryptographic heavy lifting correctly; the mistakes that matter happen around it, in how a result gets interpreted.

Mistake 1: treating VALID as a synonym for trustworthy

A valid signature from a key you pasted a minute ago and have never independently confirmed is not evidence of anything beyond internal consistency. Pair every VALID result with a fingerprint comparison against a source you trusted before this session started.

Mistake 2: pasting a partial armored block

Skipping the header or footer line, or losing a blank line during copy-paste, is the single most common cause of a spurious error. Select the entire block, including the BEGIN/END lines, rather than trying to trim it.

Mistake 3: assuming a tool that asks for uploads is just as safe

Not every "online PGP verifier" runs client-side the way torverify's does. Before pasting a real key or message into any tool, check whether it claims to process things locally or whether it silently posts your input to a server — the browser's network tab will show you the truth either way.

Worked example: verifying a message with torverify's tool

Here is the process end to end, the same steps described abstractly above, walked through against a concrete signed message.

Step 1 — obtain the key from a source you already trust

Fetch the signer's public key from a channel independent of the message you are about to check — not a copy bundled alongside the message itself.

Step 2 — paste both blocks and run the check

Drop the full public key into the first field and the full signed message into the second, then click Verify signature. The computation happens entirely in your browser tab.

Step 3 — compare the reported fingerprint, not just the verdict

Whether torverify's tool reports VALID or INVALID, note the fingerprint it displays and compare it against a copy from a second channel before treating the result as final — a VALID result against the wrong key is not a success.

When to reach for desktop GnuPG instead

This torverify page covers the common case of checking one signature quickly and privately. For managing a keyring, signing your own messages, or working offline on an air-gapped machine, a desktop tool such as GnuPG is the better fit. Both torverify's tool and GnuPG implement the same OpenPGP standard (RFC 4880), so a signature that verifies here will verify there too. The maths is identical. The choice is about workflow, not about which answer you can trust. Whichever tool you use, do it inside Tor Browser if the key or message came from an onion source, so the fetch itself does not leak your network location.

Why torverify built a browser tool anyway

Desktop GnuPG assumes a level of setup — installing software, managing a keyring — that not every reader wants for a single one-off check. torverify's browser tool exists for exactly that case, without asking anyone to trust a server in the process.

Running both, one against the other

If you already have GnuPG installed and want extra confidence, run the same key and message through both this page and your desktop keyring, and confirm they agree. Disagreement between the two would point at a bug in one implementation rather than anything about the signature itself, since both follow the same RFC 4880 rules — but it's a useful sanity check the first few times you rely on a browser-based verifier for something that matters.

Why torverify relies on PGP signatures, not just HTTPS

A reasonable question is why torverify bothers with PGP at all when a site can just serve its address over HTTPS with a valid certificate. The two solve different problems, and conflating them is exactly the gap phishing mirrors exploit.

HTTPS proves the connection; torverify needs more than that

A valid TLS certificate confirms you are talking to whoever controls the private key for that certificate — it says nothing about whether the content on the page is genuine, unaltered, or published by the project it claims to represent. A phishing mirror can obtain its own valid HTTPS certificate for its own clone domain in minutes from any certificate authority. That padlock icon proves the connection is encrypted; it never proves the address behind it is real.

torverify: PGP signatures prove authorship, independent of hosting

A PGP signature is tied to a specific offline key, not to a domain, a server, or a hosting provider. torverify's source of record can be mirrored to a dozen different domains and the signature check still works identically on every copy, because the signature travels with the data rather than with the infrastructure serving it. That is precisely the property a hosted, domain-bound certificate cannot offer.

Why torverify uses both, not one or the other

torverify.online is served over HTTPS like any other modern site, protecting the connection between your browser and this page. The PGP layer sits on top of that, protecting the actual claim — which onion address belongs to which project — independent of whether this particular domain, server, or hosting account stays under torverify's control forever. Losing the domain would not let an attacker forge a signature; losing a signing key would not, by itself, take down the site.

Algorithms torverify's tool supports

torverify's browser verifier is built on a self-hosted copy of OpenPGP.js, which implements the OpenPGP standard broadly enough to cover what real-world signed messages use in practice.

Signature schemes torverify's tool reads

RSA (2048-bit and up), ECDSA and EdDSA over standard curves including Curve25519, and the DSA legacy scheme are all supported for signature verification. If a key uses one of these, torverify's tool reads it without any special configuration.

Hash algorithms torverify's tool reads

SHA-256 and SHA-512 cover the overwhelming majority of signatures you will encounter from any actively maintained key in 2026; SHA-1 is also read for compatibility with older keys, though a signature relying solely on SHA-1 deserves extra scrutiny given its known weaknesses.

What torverify's tool does with an unsupported key format

A key using an exotic or deprecated algorithm outside this list will surface as a parse error rather than a false VALID result — torverify's tool fails loudly rather than silently treating an unreadable key as passing. If that happens, desktop GnuPG's broader algorithm support is the fallback described above.

What to do immediately after a signature verifies

A VALID result confirms the message and the key match; it does not by itself confirm the key belongs to who you think it does. Cross-check the fingerprint through a second channel before treating the result as final, and note the date — a signature made years ago on a now-rotated key is a different situation from one made this week.