OpenPGP Key Inspector & Packet Parser

PGP ("Pretty Good Privacy") was released by Phil Zimmermann in 1991 as a program anyone could use to encrypt and sign messages. To escape the single-vendor problem, the message format was standardized as OpenPGP (RFC 2440 in 1998, RFC 4880 in 2007, RFC 9580 in 2024). Today GnuPG is the most common implementation, and the same packet format also shows up in signed git commits, software-package signing, key servers, and the OPENPGPKEY DNS record.

The model is end-to-end: you and your correspondent each generate a personal key pair; whatever is encrypted for you can only be decrypted by your private key, which never leaves your machine. Instead of a central certificate authority (like TLS), trust in other people's keys comes from signing each other's keys — the "web of trust". Whether you use that web or simply compare fingerprints out-of-band (a phone call, a business card) is up to you; the format itself does not force either.

An OpenPGP "key" is really a small bundle of packets: one primary key packet (your identity anchor, usually allowed to sign), one or more User ID packets ("Alice <alice@example.com>"), self-signatures binding those IDs to the primary key, and optionally subkeys with their own binding signatures — typically a separate encryption subkey so the precious primary key can stay offline. The whole armored block you paste into this page is that bundle.

The fingerprint is the primary key packet's hash — SHA-1 (20 bytes) for v4 keys, SHA-256 (32 bytes) for v6 keys — computed over the public portion only. The key ID is just the last 8 bytes of a v4 fingerprint (first 8 for v5). Fingerprints are what you compare out-of-band to make sure nobody swapped the key on its way to you; key IDs are a short handle for key servers and are not collision-safe against a determined attacker.

Algorithm ID	Name	Typical use in a key
1	RSA	Classic all-rounder; 2048–4096 bits, sign and/or encrypt
19	ECDSA	NIST curves (P-256 etc.), signing
18	ECDH	Curve25519/P-256 key agreement, encryption subkeys
22	EdDSA	Ed25519 signing (the modern default in GnuPG 2.4+)
25	X25519	Encryption subkeys paired with Ed25519 primaries (v6 keys)

A private key block carries the secret numbers after the public part: an S2K usage octet saying how they are protected (0 = unprotected, 254/255 = passphrase-derived key with a cipher), then the secret MPIs and a checksum. This page shows that protection mode but never asks for a passphrase and never attempts decryption of the secret material.

Under the armor, every OpenPGP object is a sequence of packets. Each starts with a tag byte: the old format packs a 4-bit packet type and a length-type into it, the new format (CTB, bit 6 set) uses a 6-bit type and length bytes that can even describe data in partial chunks. Common tags: 6 = public key, 5 = secret key, 14 = subkey, 13 = user ID, 2 = signature, 4 = one-pass signature, 11 = literal data, 8 = compressed data, 18 = encrypted-and-MDC-protected data. This page prints the tag, header format, length and a hex dump for every packet it finds, and errors with a byte position when a packet header is malformed.

Signature packets carry their metadata in hashed and unhashed subpacket areas. Only the hashed area is covered by the signature itself; the unhashed area (historically used for the issuer key ID) can be freely rewritten by anyone in transit, so readers must treat it as a hint, never as fact. The self-signature on a User ID is what actually binds the name to the key; a key packet alone, pasted by itself, proves nothing about who owns it.

ASCII armor is the text wrapper: -----BEGIN PGP PUBLIC KEY BLOCK-----, optional headers such as Version: or Comment:, base64 of the packet stream, and a final =xxxx line holding a 24-bit CRC. That CRC only catches transport corruption — flip one base64 character and this page flags it — but it is not a signature and proves nothing about authorship.

• Trusting a key without comparing fingerprints. Anyone can generate a key with any name. The fingerprint comparison over a channel you already trust (in person, by phone) is the entire authentication step.
• Confusing the armor CRC with a signature. A "CRC OK" badge means the base64 survived the trip, nothing more. Verification is a cryptographic operation this page intentionally does not perform.
• Using key IDs as identity. 64-bit key IDs can be forged by an attacker with modest computing power (a "key ID collision"); always quote full fingerprints.
• Pasting real private keys into web pages. Even a local, no-upload page like this one is a habit you do not want to build. The samples here are throwaway keys generated for the demo.
• Assuming "PGP MESSAGE" means encrypted. The armor label says nothing about content — the sample message on this page is signed but plaintext, and packet tag 18 vs 11 is what actually distinguishes encrypted from literal data.
• Importing v3 keys. Version 3 keys (pre-1996 design, weak 16-bit key IDs) have been deprecated since 2014; this inspector rejects them on purpose.

Does this verify signatures? No. It parses and displays. Signature verification needs the full RFC 9580 hash-trailer construction, the signer's public key, and a decision about whether you trust that key — the job of GnuPG or an OpenPGP library.

How is this different from openpgp.js? openpgp.js is a full implementation (encrypt, decrypt, sign, verify) you embed in your app; this page is a dependency-free inspector for reading and auditing OpenPGP structures in the browser.

Can it read my GnuPG export? Yes — v4, v5 and v6 keys, detached signatures and messages. Version 3 keys are refused with a note (deprecated since 2014).

Why is there a hex input mode? Raw OpenPGP data is binary; if you have a hex dump of a keyring or a .gpg file, paste the hex and the parser treats it exactly like the decoded bytes.

Is anything uploaded? No. Parsing, fingerprinting and report generation all happen in this tab; the page runs entirely in your browser.