Last updated: · By

PGP Key Inspector: Fingerprints, Identities, Subkeys and Signatures in an OpenPGP Key

An OpenPGP public key reveals far more than its fingerprint: the names and email addresses its owner attached, when each identity was added, every subkey with its creation and expiry dates, which other keys vouched for it, any revocation, the owner’s preferred keyserver and sometimes an embedded photo. Paste a key, a detached signature or a signed message below, or drop a .asc/.gpg file, and the inspector decodes every packet in your browser — nothing is uploaded — then lists the pivots: exact-match searches for the fingerprint and key ID, keyserver lookups and email pivots. Investigators care because keys are long-lived identifiers: researchers who extracted 21,544 PGP keys from dark-net market archives describe vendors using a public key “as identification across markets” Booij, Verburgh, Falconieri & van Wegberg, “Get Rich or Keep Tryin’”, IEEE EuroS&PW 2021 (read 10 Oct 2026).

Structure is parsed; signatures are not cryptographically verified. The inspector reads what the packets say — who claims to have signed, when, and with which key — but does not check any signature maths. A forged or edited key can say anything. Everything runs in this browser tab; nothing is sent anywhere unless you press the keys.openpgp.org button, which says what it sends.
Drop a .asc / .gpg / .pgp / .sig file here or press Enter to choose one · binary or armored

Ctrl+Enter (or ⌘+Enter) inspects · accepts public key blocks, keyrings, detached and inline signatures, cleartext-signed messages, revocation certificates and encrypted messages (recipient key IDs only) · up to 25 MB · private keys are refused · link a fingerprint with #fpr=<hex>.

What does a PGP public key reveal, at a glance?

A “PGP key” you find on a forum, a market profile or a contact page is an OpenPGP certificate: a sequence of packets — a primary key, User IDs, optional User Attributes, subkeys and the signatures that bind them together RFC 9580 OpenPGP, section 10.1 Transferable Public Keys (July 2024). Each field below is decoded by the inspector.

What you seeWhere it is storedWhy it mattersCaveat
Fingerprint and key IDComputed from the public-key packet (section 5.5.4)Stable identifier to search verbatim across sites, pastes and keyserversv4 key IDs are the last 64 bits of the fingerprint, v6 the first 64 bits
Key creation time4-octet field in the key packet (5.5.2)Earliest date the key could have been usedSet from the creator’s clock — can be backdated
Names, comments, emailsUser ID packets (5.11)Email and name pivots; several names on one keyFree text the owner typed; nothing checks it
When each identity was addedSignature Creation Time of each self-signature (5.2.3.11)Timeline of identities added or refreshedOnly the self-signatures present in this copy
Photo IDUser Attribute image subpacket (5.12.1)The owner’s own embedded JPEGNot necessarily a photo of the owner
Subkeys, usage, expirySubkey packets + binding signatures: Key Flags, Key Expiration Time (5.2.3.29, 5.2.3.13)Key rotation history; which subkey a message was signed or encrypted withExpiry can be extended later by a new self-signature
RevocationKey, subkey or certification revocation signatures, Reason for Revocation (5.2.3.31)Owner retired, superseded or reported compromise of a keyOnly if the revocation is in your copy
Third-party certificationsCertification signatures by other keys (0x10–0x13)Web-of-trust links to other keys and peoplekeys.openpgp.org does not publish these by default
Preferences, keyserver URL, notationsSelf-signature subpackets 11, 21, 22, 23, 24, 20, 39Hints about software and a URL or domain the owner choseSoftware defaults, not unique fingerprints of a person
Armor headersVersion: / Comment: lines (6.2.2)Software or website that exported the keyAnyone can edit or delete them
Signature issuer and timeIssuer Key ID / Issuer Fingerprint and creation time (5.2.3.12, 5.2.3.35)Which key signed a message, and when it says it didNot verified here; check with the signer’s key in GnuPG or Sequoia
Encrypted-message recipientsPKESK packets (5.1)Key IDs of everyone a message was encrypted toA recipient can be anonymous (all-zero key ID)
Literal file name and dateLiteral Data packet (5.9)Original file name the sender’s software storedOften blank or set by software

Section numbers refer to RFC 9580 OpenPGP (July 2024, read 10 Oct 2026), which replaced RFC 4880 and is the specification the parser follows.

How is a key fingerprint calculated?

RFC 9580 defines the fingerprint by key version RFC 9580, section 5.5.4 Key IDs and Fingerprints:

  • Version 4 (almost every key in circulation): SHA-1 over the octet 0x99, the 2-octet length of the key packet body, and the body itself. The 64-bit key ID is the low (last) 16 hex digits of the 40-digit fingerprint.
  • Version 6 (new in RFC 9580): SHA-256 over 0x9B, a 4-octet length and the body. The key ID is the high (first) 16 hex digits of the 64-digit fingerprint.
  • Version 3 (PGP 2.x, deprecated): MD5 of the RSA modulus and exponent, with the key ID taken from the modulus. The inspector shows the v3 key ID but does not compute the MD5 fingerprint.

Subkeys use the same formula, so a subkey fingerprint found in a signature or an encrypted message can be matched back to its primary key. The inspector hashes with the browser’s Web Crypto API and compares nothing against a server unless you ask it to.

ASCII armor may end with a CRC-24 checksum line starting with =. RFC 9580 makes that line optional and says an implementation must not reject data when it is missing or wrong RFC 9580, section 6.1 Optional Checksum, so the inspector reports a mismatch as a warning — a hint that the paste was edited or damaged — and keeps parsing.

How do investigators pivot from a PGP key?

  • Search the exact fingerprint and the long key ID. Keys are pasted into profiles, forum signatures, pastes and archived pages. Search engines and dark-web indexes match the plain and the grouped form differently, so the inspector builds both queries. Researchers have linked vendor pseudonyms across dark-net markets through shared PGP keys Booij et al., IEEE EuroS&PW 2021: “By using PGP-keys, it becomes possible to track dark net market vendors across multiple platforms”.
  • Check keyservers. keys.openpgp.org serves keys by fingerprint, key ID or verified email through its VKS API; hex must be upper case with no 0x prefix keys.openpgp.org: VKS API documentation (read 10 Oct 2026). It distributes identity information “only … with consent”, after the owner verifies the address keys.openpgp.org: About (read 10 Oct 2026), and does not publish third-party certifications by default keys.openpgp.org: FAQ (read 10 Oct 2026). A server copy with fewer User IDs than the pasted key is therefore normal. keyserver.ubuntu.com speaks the older HKP protocol, where a fingerprint or key ID is searched as /pks/lookup?search=0x… IETF draft-gallagher-openpgp-hkp-10, OpenPGP HTTP Keyserver Protocol (29 Apr 2026, work in progress); in our tests on 10 October 2026 it returned “not found” for some requests and the key for identical repeats, so retry before concluding a key is absent.
  • Pivot on every email and domain. Each User ID email goes to Email OSINT; the domain to Domain OSINT. Notation names such as [email protected] also carry a domain the owner chose.
  • Follow the web of trust. Certifications name the issuer’s key ID or fingerprint. Each issuer is a new key to look up — often a colleague, a project or a signing party.
  • Build a timeline. Key creation, each identity’s first self-signature, subkey creation and revocation dates show when an identity appeared and when it was abandoned. Compare them with account creation dates and posting history, keeping in mind that timestamps come from the creator’s clock.
  • Dark-web indexes. Ahmia indexes onion sites from the clear web. Its search form uses a per-session token, so a pre-filled link lands on its home page: copy the fingerprint and search there. The inspector never contacts onion services.

For the wider workflow — and the OpSec and legal guardrails that go with it — read the Dark Web OSINT guide.

What can’t a PGP key prove?

  • Who owns it. A User ID is text the key holder typed. Anyone can create a key with any name and email. Only the email-verification step of a service like keys.openpgp.org, or a certification from someone you trust, ties an address to a key.
  • When it was really made. Creation and signature times come from the creator’s computer. To test this page we generated a key dated 15 March 2019 by running GnuPG with --faked-system-time; it looks exactly like a 2019 key.
  • That a signature is genuine. This page does not verify signatures. A copied or edited signature can carry any issuer ID. Verify with the signer’s public key in GnuPG, Sequoia or another OpenPGP implementation.
  • That a field is covered by the signature. Subpackets in the unhashed area are not protected by the signature and can be changed by anyone RFC 9580, section 5.2.3.8. The inspector marks them.
  • That a key is the only one. Vendors and other users can share keys or rotate to new ones, which is why the market study above warns that counting keys does not directly count people.

Public keys are published so that others can find and use them, and decoding a key you already hold is ordinary parsing; this page stores nothing and sends nothing unless you press the keys.openpgp.org button. The usual rules of dark-web OSINT still apply: stay on public information, do not interact with illegal marketplaces or buy anything to “test” a vendor, document how and where you obtained each key for chain of custody, and involve legal counsel for sensitive work — evidence from the dark web is often challenged on how it was collected. Names, emails and photos inside a key are personal data in many jurisdictions, so handle exports accordingly. This page is information, not legal advice.

How was the inspector tested?

The parser that runs this page (pgp-key-inspector.js) was run in Node.js against keys generated with GnuPG 2.4.4 on 10 October 2026, and every value was compared with gpg --with-colons --show-keys: 398 checks, 0 mismatches.

  • Keys: Ed25519 with a Curve25519 encryption subkey expiring in 2 years, an Ed25519 signing subkey expiring in 1 year and a revoked RSA authentication subkey; two User IDs with different names; a JPEG photo ID; a preferred-keyserver URL; a self-signature notation; a third-party certification by an RSA-3072 key; a revoked key; DSA-2048 + Elgamal-2048; ECDSA P-384 and brainpoolP256r1; and an RSA-2048 key backdated to 2019 with a second identity added in 2026. Fingerprints, key IDs, creation and expiry times, key sizes, revocation status and User IDs matched for primaries and subkeys, armored and binary.
  • A real published key: the Tor Browser Developers signing key (EF6E 286D DA85 EA2A 4BA7 DE68 4E2C 6E87 9329 8290) as served by keys.openpgp.org, with 8 subkeys, matched GnuPG too.
  • Version 6: the sample certificate in RFC 9580 appendix A.3 gives the published primary fingerprint CB186C4F…BAD9ACC9 and subkey fingerprint 12C83F1E…A9930885; the v4 sample key in A.1 gives C959 BDBA … 9796 5A9A and its 2014-08-19 14:28:27 creation time RFC 9580, Appendix A Test Vectors. The cleartext-signed (A.6), inline-signed (A.7) and encrypted (A.8) samples give the published issuer and recipient fingerprints.
  • Signatures: cleartext, detached (armored and binary), inline signed with ZIP compression, uncompressed and armored, and GnuPG revocation certificates — issuer key IDs and creation times matched gpg --list-packets.
  • Malformed input: truncated blocks, missing END lines, invalid base64, a flipped CRC-24, plain text, non-OpenPGP binary and private keys each produce a specific message instead of a crash.
  • In headless Chromium at 375 px and 1280 px: file drop and keyboard file picker, examples, #fpr= links, photo rendering, CSV/JSON export, the keys.openpgp.org comparison with mocked 200/404/400/429 responses, hostile User IDs rendered as text, and no horizontal scrolling.

Sources

External search and keyserver links on result cards go to third-party sites, which receive what is in the link (a fingerprint, key ID or email).

Frequently asked questions

How do I find the fingerprint of a PGP public key?

Paste the armored key block or drop the .asc or .gpg file into the inspector. It computes the fingerprint in your browser the way RFC 9580 defines it: SHA-1 over 0x99, a 2-octet length and the key packet for version 4 keys (40 hex digits), and SHA-256 over 0x9B, a 4-octet length and the key packet for version 6 keys (64 hex digits). The results match gpg --with-colons --fingerprint. In GnuPG itself, run gpg --show-keys --with-fingerprint file.asc.

What is the difference between a PGP fingerprint and a key ID?

The fingerprint is the full hash of the key: 40 hex digits for a version 4 key, 64 for version 6. The long key ID is 16 hex digits taken from it, the last 16 for version 4 and the first 16 for version 6. Short 8-digit key IDs are easy to collide, so search and compare the full fingerprint whenever you have it.

Can a PGP key reveal who someone is?

It can reveal what the owner chose to put in it: names, email addresses, comments, sometimes a photo, a preferred keyserver URL or a notation with a domain, plus the dates each was added and which other keys certified it. None of that is verified by the key itself. Treat every User ID as a claim and confirm it with independent sources, such as the email address being verified on keys.openpgp.org or the same fingerprint published on an account the person controls.

Why do investigators search for PGP fingerprints on the dark web?

Because a key is hard to replace without losing reputation, vendors and other actors tend to keep it. Academic work on dark-net market archives found that vendors used their public key as identification across markets and linked pseudonyms across platforms through shared keys. Searching the exact fingerprint and long key ID in search engines, keyservers and onion indexes such as Ahmia can surface the same key under other names.

Does this tool verify PGP signatures?

No. It parses the structure and shows what the packets state: signature type, issuer key ID or fingerprint, creation time, hash algorithm and subpackets. It does not check the signature mathematics, so a forged or altered signature looks the same. To verify, import the signer's public key into GnuPG or Sequoia and run the verify command on the original file.

Is my key or message uploaded anywhere?

No. Parsing, hashing and the investigator notes run in your browser tab. The only network request the page can make on its own is the optional keys.openpgp.org comparison, which runs only when you press its button and sends just the fingerprint or key ID. Search and keyserver links open third-party sites that receive what is in the link.

Why does keys.openpgp.org show fewer user IDs than the key I have?

keys.openpgp.org distributes identity information only with consent: an email User ID is published after its owner verifies the address. It also does not publish third-party certifications by default, or identities that are not email addresses, such as photo IDs. The key material and subkeys are still served by fingerprint. The comparison button lists which User IDs the server publishes and which exist only in your copy.

Can the creation date of a PGP key be faked?

Yes. Key and signature timestamps come from the clock of the computer that made them, and GnuPG has a --faked-system-time option. For testing this page we created a key that looks as if it was made in March 2019. Use creation dates as the key holder's claim, and corroborate them with when the fingerprint first appeared in archives, posts or keyserver records.