How do PGP/GPG detached signatures work for verifying website authenticity?
This fact-check may be outdated. Consider refreshing it to get the most current information.
Executive summary
Detached PGP/GPG signatures let a publisher create a small signature file (e.g., .asc or .sig) that, when checked against the original download and the publisher’s public key, proves the file’s integrity and that it was signed with the corresponding private key (both the data and the signature file are required for verification) [1] [2]. Verification succeeds when GPG finds the signer’s public key, hashes the data, and applies the signature-check algorithm to produce “Good signature”; if the public key is missing or the file was altered the check fails [3] [4].
1. How detached signatures actually work — the mechanics in plain sight
A detached signature is an OpenPGP signature stored separately from the data it protects; the signer creates the signature with their private key (gpg --detach-sign) and consumers run gpg --verify supplying both the signature file and the original file. GPG then reads the signer's public key from your keyring, computes the hash of the data, and applies the OpenPGP verification algorithm; a match yields “Good signature” [1] [4] [2].
2. Why websites ship detached signatures — flexibility and practical benefits
Websites distribute detached signatures so users can download/verifiably check large binaries or archives without altering the files themselves. Detached signatures keep the original file unchanged and can be distributed alongside or separately from the data, which is convenient for mirrors and package repositories [2] [5]. Red Hat documents this flow for vulnerability scripts and products, showing the .asc signature alongside the artifact [3].
3. The verification inputs you must supply — nothing magic, three pieces
A correct verification needs: (a) the original file, (b) the detached signature file, and (c) the signer’s public key in your keyring (or supplied explicitly). GPG expects to locate the public key locally and will report “public key not found” if it’s missing; users can import the publisher’s key from a keyserver or a website before verifying [1] [4] [6].
4. Where verification can break — corruption, wrong file, or missing key
Signatures fail when the signed data differs even by a single whitespace or when you use a different file than the one signed — detached signatures verify the exact bytes that were hashed at signing time [7]. GPG will also fail if it can’t find the signer’s public key in your keyring; guidance across sources is to fetch/import the correct public key and compare fingerprints when possible [4] [8] [6].
5. Trust and authenticity — signature validity is not equal to web-trust
A “Good signature” proves the file was signed with the corresponding private key, but it does not by itself tell you whether the public key you used actually belongs to the genuine publisher unless you have independently validated that key [4] [8]. Practical verification workflows therefore include fingerprint checks on the publisher’s published key or using a known, trusted keyring [8] [9].
6. Usability tradeoffs and deployment notes — why people get tripped up
GPG tooling expects three inputs and subtle filename behaviour (gpg may try to infer the signed file name from the sigfile), which confuses users; tools like gpgv or supplying an explicit keyring can simplify scripted or repeatable checks [10] [9]. Publishers often ASCII-armour signatures (-a) so the .asc is human-readable and easier to host, and they warn that not protecting your private key (e.g., no passphrase) would let attackers forge signatures [11].
7. Practical step-by-step (high level) — what to do on a website download
Download the file and its detached signature (.sig/.asc), obtain the publisher’s public key from their site or a keyserver and import it to your keyring, then run gpg --verify signaturefile file. Expect messages like “Good signature” or “public key not found”; if you see “BAD signature” check for file corruption, wrong transfer mode, or a mismatched file [5] [3] [7].
8. Conflicting or missing angles in current reporting
Available sources explain mechanics, common failures, and practical guidance but do not provide a unified standard on how websites should publish public-key fingerprints or defend against key-substitution attacks; some recommend fingerprint comparisons [8] while other documentation focuses on procedural commands and tool options [1] [11]. Sources do not mention a single, authoritative web practice for binding keys to domain names in the HTTP context (not found in current reporting).
Limitations: this summary uses only the provided documentation and how‑to resources; it does not attempt to assert matters not covered by those sources and cites the exact passages that describe mechanics, failure modes, and operational tips (p1_s1–[1]3).