PGP signature questions: sign, clearsign, detached, verify

GnuPG computes a hash of the data (a short, unique summary, such as SHA-512) and signs that hash with your private key. Anyone with your public key can recompute the hash and check the signature. If even one byte of the data changes, the check fails. Signing does not hide anything: a signed but unencrypted file is still readable by everyone. You can sign and encrypt in one step with gpg -se -r recipient file.

Use -u FINGERPRINT to choose which of your keys signs, if you have more than one.

Use a detached signature for files and software releases, and PGP/MIME (what Thunderbird, GpgOL and other current mail clients do) for email. The GnuPG developers now advise against cleartext signatures except for legacy uses. They look simple, but it is easy to trick a reader into believing unsigned text is signed: with fake armor lines using four dashes or look-alike Unicode dashes, extra armor header lines, terminal control characters, or very long lines. Only the verifying program can tell you exactly what was signed.

Cleartext signatures date from the first PGP versions, built for bulletin boards and mail at a time when most readers did not have PGP installed. PGP/MIME, first specified in 1996 (RFC 2015), gradually replaced it.

That is dash-escaping. In a cleartext signature, any line that starts with a dash gets "- " (dash, space) added in front, so it cannot be mistaken for a -----BEGIN line. RFC 9580 also recommends escaping lines that start with "From " followed by a space, because some mail systems alter them. The signature is computed over the original text, and the verifying program removes the escapes again. Cleartext signatures also strip trailing spaces from each line, which is another reason to prefer detached signatures for files.

Give the signature file first and the data file second:

gpg --verify file.tar.gz.asc file.tar.gz

Do not add --output here; with a detached signature there is nothing to write. If you give only the signature file, GnuPG may try to find the data file by stripping the suffix, but the manual strongly discourages relying on this: always name the data file. Worked examples for real downloads are in verifying downloads.

Have GnuPG write out the text that was actually signed, and read or use only that output:

gpg --verify -o signed.txt message.asc

Do not trust what your terminal or text editor shows around the signature block. The GnuPG manual notes that gpg verifies only the cleartext signed data, not any extra data outside it; anything there, or hidden with control characters, is not covered by the signature.

gpg: Signature made Wed 04 Nov 2026 02:03:08 AM EST
gpg:                using EDDSA key F5CBB616339D27659CF3A6A0DA9AA34BBCE56058
gpg:                issuer "alice@example.org"
gpg: Good signature from "Alice Example <alice@example.org>" [ultimate]

It means the data is exactly what the holder of key F5CB…6058 signed. The word in brackets is GnuPG's opinion of whether that key really belongs to the person named: [ultimate] for your own keys, [full] or [marginal] for keys validated through your certifications, [unknown] when nothing confirms it, and [expired] or [revoked] when the key is no longer valid. A good signature from an [expired] key, followed by "Note: This key has expired!", is usually an old signature that was made while the key was still valid.

gpg: Good signature from "Alice Example <alice@example.org>" [unknown]
gpg: WARNING: The key's User ID is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: F5CB B616 339D 2765 9CF3  A6A0 DA9A A34B BCE5 6058

The signature is mathematically good, but you have not told GnuPG that this key belongs to Alice. Anyone could have made a key with her name. Compare the printed fingerprint with one you got from a trusted place (Alice in person, the project's website over HTTPS, a printed card). If it matches, certify the key locally with gpg --quick-lsign-key F5CBB616339D27659CF3A6A0DA9AA34BBCE56058 and the warning goes away. If it does not match, treat the signature as worthless. The trust levels are explained in key signatures and the web of trust.

The data has changed since it was signed, or the signature does not belong to this data. Do not use the file. Download it again from the original source and verify again. With text files, a harmless cause can be a program that changed line endings or character encoding; with downloads, it can be an incomplete transfer. If a fresh copy still fails, tell the publisher. GnuPG exits with status 1 for a bad signature, so scripts can catch it.

The GnuPG developers recommend gpgv for scripts. It checks only against keys in its own keyring (trustedkeys.kbx or trustedkeys.gpg in the GnuPG home directory) and returns success only for a good signature from one of those keys:

gpgv file.tar.gz.asc file.tar.gz

With full gpg, add --assert-signer FINGERPRINT: gpg then exits with 0 only if a valid signature from that key is present. Never decide success by searching the output for the words "Good signature".

No. The signature is bound to the hash of the exact data you signed. Moved to other data, it fails to verify. Someone can, however, take a message you really signed and pass it on in a new context, for example forwarding an old "yes, approved" to a different person. If context matters, put it in the signed text: the date, the recipient and what you are approving.

Only as reliable as the signer's clock and honesty. The creation time is written by the signer's own software, and anyone can set their computer's clock to any date before signing. A signature date shows when the signer claims to have signed, not proof of when it happened. If you need proof of time, use a trusted timestamping service in addition.

That depends on the country and on what the signature is used for. Many legal systems accept electronic signatures in general, but some documents require specific forms or certified providers, and a PGP key alone does not prove a real-world identity to a court. Ask a lawyer where you live if it matters. This FAQ cannot give legal advice.