PGP Signature Verification — Key Management, Kleopatra & GnuPG Guide

Choosing & Generating Your Key Pair: Ed25519 vs. RSA-4096

For a new personal key, Ed25519 is the right default: the public key fits in 32 bytes, a signature in 64, and signing is fast because the algorithm is deterministic — no random number needed at sign time. RSA-4096 earns its place only for compatibility: old OpenPGP smartcards, pre-2018 clients, and some hardware tokens do not speak elliptic curves.

In GnuPG, gpg --full-generate-key walks through the choice — option (9) for elliptic curves, then (1) for Curve 25519:

$ gpg --full-generate-key
Please select what kind of key you want:
   (9) ECC (sign and encrypt)
Your selection? 9
Please select which elliptic curve you want:
   (1) Curve 25519        *default*
Your selection? 1
Key is valid for? (0) 2y
Real name: Alice
Email address: alice@example.org

In Kleopatra — the certificate manager bundled with Gpg4win on Windows and included in Tails — the same pair is made from File → New OpenPGP Key Pair, with the curve selector under Advanced Settings.

Two choices at creation time pay off later. Issue a revocation certificate immediately — gpg --output revoke.asc --gen-revoke alice@example.org — and store it offline; if the machine holding the secret key is lost or seized, that file is the only way to mark the key as dead. And set an expiry of one to two years: you can push it forward while you hold the private key, but a permanently lost key at least stops looking valid on keyservers.

Checking someone else's signed text starts with their public key. Import it once, read the fingerprint it reports, and confirm that fingerprint on a channel you already trust — the signer's published page, a previously verified signed post, or release notes. A key that arrives attached to the very message it is supposed to authenticate proves nothing.

$ gpg --import release-key.asc
gpg: key 10A45F3B8E2D6C71: public key "Release Signing <release@example.org>" imported
gpg: Total number processed: 1
gpg:               imported: 1

$ gpg --fingerprint release@example.org
pub   ed25519 2025-03-14 [SC] [expires: 2027-03-14]
      9F3C 7A21 44D8 91B0 6E55  2C88 10A4 5F3B 8E2D 6C71
uid           [ unknown] Release Signing <release@example.org>
sub   cv25519 2025-03-14 [E] [expires: 2027-03-14]

The fingerprint is the identity: 40 hexadecimal characters in groups of four; the last 8 are only a short key ID, convenient for searching and useless for trust. With the fingerprint confirmed, verification is one command on a cleartext-signed notice — the format mirror lists, signed canaries, and forum announcements use because the text stays readable inside the armor:

$ gpg --verify notice.txt
gpg: Signature made Sat 31 Oct 2026 02:14:07 PM UTC
gpg:                using EDDSA key 10A45F3B8E2D6C71
gpg: Good signature from "Release Signing <release@example.org>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 9F3C 7A21 44D8 91B0 6E55  2C88 10A4 5F3B 8E2D 6C71

Copy the signed block whole, from -----BEGIN PGP SIGNED MESSAGE----- through -----END PGP SIGNATURE-----: the signature covers every byte between the markers, so a dropped blank line or re-wrapped paragraph changes the result. Kleopatra runs the identical check without a terminal — copy the armored block, pick Clipboard → Decrypt/Verify, and double-click the certificate name in the result window to read the same fingerprint. That clipboard path is the one used in our signed mirror-list verification walkthrough.

Software releases ship the signature separately — a .asc or .sig file next to the download. Tor Browser's installers are the everyday example: fetch the installer and its matching .asc, import the Tor Browser Developers signing key once, then run gpg --verify tor-browser-installer.asc tor-browser-installer.exe. The second argument names the file the signature covers; swap the order and GnuPG hashes the wrong thing.

Good signature from proves the bytes you verified are the bytes that were signed; Primary key fingerprint proves whose key did the signing. The line that scares newcomers — WARNING: This key is not certified with a trusted signature! — prints on nearly every first-time check and means only that your local keyring has no ownertrust entry for this key. The signature already passed; the warning is about your trust settings, not the math. The output that does mean trouble is BAD signature: the text was modified after signing, by as little as one byte or a line-ending change, and its content should be treated as unsigned.

The failures that cost people money sit in the gap between what GnuPG prints and what a tired reader sees. Three come up constantly:

1. Short key IDs were brute-forced years ago. The 10A45F3B8E2D6C71 in the using EDDSA key line is just the low 32 bits of the fingerprint. Back in 2014 the Evil32 project generated colliding short IDs for the entire Web of Trust strong set, and a modern GPU reproduces the trick in minutes — a matching 8-character ID proves nothing at all.
2. Status lines can be typed into the message. A scammer can paste the text gpg: Good signature from "Release Admin" inside a cleartext block and sign the whole thing with a throwaway key. Inside the message that line is only content — real GnuPG status appears on your terminal's stderr or in Kleopatra's result pane, never within the signed text.
3. Whitespace edits flip good signatures to BAD. A mail client that re-wraps lines, or a paste that drops a blank line, breaks verification on a genuine message — and phishers exploit the confusion by coaching readers to "ignore the broken signature." The right response to a failed check is a fresh copy of the signed text, not trust anyway.

The habit to build: ignore the name in the UID line, watch the Good signature verdict, and compare the printed fingerprint against the 40 characters you already confirmed — in that order, every time.

Every "online PGP verify" or "PGP decrypt online" website has the same defect: your plaintext and the fingerprint pass through somebody else's server, and the green checkmark it returns is whatever that operator chooses to show you. Encrypt and verify on your own machine — the only thing that should reach a browser form is finished armor, a -----BEGIN PGP MESSAGE----- block produced by your local keyring.

Two default OS features quietly break that isolation. Windows keeps a clipboard history under Win+V and can sync it to a Microsoft account — turn both off before copying decrypted text or passphrases. macOS offers to store the key passphrase in Keychain, which iCloud pushes to every logged-in device; decline that dialog and let the passphrase live in your head or an offline password manager such as KeePassXC.

Keep the private key off networks the same way: gpg --export-secret-keys --armor you@example.org > secret-backup.asc onto an encrypted USB stick or a Tails persistent volume, next to the revoke.asc from earlier — never into cloud storage or an email draft. Gpg4win on Windows, GPG Suite on macOS, and stock GnuPG on Linux cover everything on this page; signed installers and the full manual live at gnupg.org, and openpgp.org maintains the client list and the standard itself. The browser side of the same workflow — Tor Browser's Safest level, Tails, clipboard hygiene — is covered in our Tor & OPSEC safety guide.

Once a keyring is set up, the whole check costs under a minute. The one step no software automates is the fingerprint comparison — pull the expected 40 characters from a second, independent channel before acting on anything the signed text tells you to do.