OpenPGP インスペクター

Everything is a packet

OpenPGP data — a key, a signature, a message — is a sequence of packets, each with a tag that says what it is. RFC 9580, published in 2024, is the current specification; it obsoletes RFC 4880, which most deployed software still speaks. A public key is a Public-Key packet followed by User ID packets with their self-signatures, then Public-Subkey packets with their binding signatures. A detached signature is a lone Signature packet. A signed message wraps a One-Pass Signature, a Literal Data packet with the content and the Signature, often inside a Compressed Data packet. The inspector parses every packet itself — the equivalent of gpg --list-packets — and shows its tag, offset, length and decoded fields: key algorithms and sizes, fingerprints, signature types, every hashed and unhashed subpacket (creation time, expiry, key flags, issuer fingerprint, preferences, notations), literal-data names and dates, compression and the session-key packets of encrypted messages. Compressed data is inflated so the packets inside are listed too.

The text form is ASCII armor: base64 between -----BEGIN PGP …----- lines, with optional headers. Its CRC-24 checksum became optional in RFC 9580; when one is present, the inspector checks it and reports a damaged block.

Keys: v4, v6 and what makes them valid

A v4 key's fingerprint is a SHA-1 hash; an RFC 9580 v6 key uses SHA-256, salts its signatures and introduces native Ed25519, X25519, Ed448 and X448 algorithms. Whether a key can be used is decided by its signatures: a user ID counts only with a valid self-signature, a subkey only with a valid binding signature, and the newest self-signature decides the key flags (certify, sign, encrypt, authenticate) and the expiry. The inspector evaluates each key, user ID and subkey at the current time and reports expired, revoked and badly bound ones, RSA keys below 2048 bits, deprecated DSA and Elgamal, and SHA-1 self-signatures. The post-quantum algorithm identifiers 30–36 (the ML-DSA and ML-KEM composites with Ed25519, Ed448, X25519 and X448, and SLH-DSA) are recognised and their structure shown, though no browser library can evaluate them yet. The v5 keys of the competing LibrePGP draft, which GnuPG can produce, are reported as unsupported rather than misread.

Three ways to sign

• Detached — the signature is a separate .sig or .asc file and covers a file you supply. A binary signature (type 0x00) covers the exact bytes; a text signature (0x01) covers the text with normalised line endings.
• Cleartext — -----BEGIN PGP SIGNED MESSAGE-----: readable text, dash-escaped where a line starts with a dash, followed by its signature; the text is shown as it was signed.
• Inline — -----BEGIN PGP MESSAGE-----: the content and the signature travel together in packets; the inspector shows the file name and size the message carries.

Verification needs the signer's public key: paste it, or keep it next to the signature in the same text. A good signature from a key that has expired since is still good — the inspector says when the key expired. A signature that is mathematically correct but uses what OpenPGP.js no longer accepts — a SHA-1 data signature, a short RSA key — is reported as rejected by current policy, separately from a signature that is simply wrong, so you can tell an old signature from a forged one.

The examples were made from this site's published test keys with OpenPGP.js and GnuPG 2.4.7, whose gpg --verify accepted every GnuPG signature. Git commits signed with GPG are checked by Git itself; Git's errors “gpg failed to sign the data” and GnuPG's “Can't check signature: No public key” are explained in the error database. Whether to sign commits with SSH instead is discussed in SSH vs GPG commit signing, releases in Sigstore vs GPG signing, email in S/MIME vs OpenPGP, and encryption in age vs GPG. SSH signatures are verified by the SSH signature verifier.