OpenPGP Key Lookup

An OpenPGP public key is a small file that anyone may hold. That is its whole point. You hand it out so that people can encrypt messages that only you can read, and so that they can check signatures that only you could have made. The trouble starts with the word “you”. Nothing in the file proves who made it.

A key is a sequence of packets, each a short header followed by a body. The public key packet carries a version number, the moment the key was created, an algorithm number and the public numbers themselves. After it come user ID packets, usually a name and an email address, and signature packets that tie those names, the key’s settings and any subkeys to the primary key. RFC 9580, published in July 2024, is the current description of all of this. It replaced RFC 4880, which had served since 2007.

What a fingerprint is, and why it is computed rather than read

A fingerprint is a hash of the public key packet. It is not stored anywhere in the key; any program that reads the key computes it again. For a version 4 key the recipe is short: take the single byte 0x99, then the length of the packet body as two bytes, then the body itself, and run SHA-1 over the lot. The result is 160 bits, written as 40 hex digits. The key ID is simply the last 16 of those digits. Version 6 keys, new in RFC 9580, use the byte 0x9B, a four-byte length and SHA2-256, which gives 64 hex digits, and their key ID is taken from the front instead of the back.

Here is the arithmetic on a real key. The example on this page is an Ed25519 key made with GnuPG for documentation, with a user ID at the reserved domain example.org. Its public key packet body is 51 bytes long, so the hashed input is 0x99, then 0x00 0x33, then those 51 bytes: 54 bytes in all. SHA-1 over them gives 9E05 544E A3A6 E768 1D10 87AB ABFA 977C 6C69 C750. The last 16 digits, ABFA977C6C69C750, are the key ID. Open the tool, press the example, and every one of those numbers is recomputed in your browser from the armored text.

Because the fingerprint depends on every byte of the key material and the creation time, two different keys will not share one in practice. That is what makes it useful as a name. A key ID is far weaker. Sixty-four bits are enough to look a key up, but the standard itself warns that key IDs need not be unique and that two keys can share one. The eight-digit short form is weaker still, which is why keys.openpgp.org accepts only the long one.

SHA-1 is the awkward part of the story. Researchers published the first SHA-1 collision in 2017, and chosen-prefix collisions became practical by 2020; the paper that showed it was aimed at the PGP web of trust. NIST has said SHA-1 should be phased out by the end of 2030. RFC 9580 notes that implementations cannot simply drop it while version 4 keys exist, because their fingerprints are defined with it. Version 6 fingerprints use SHA2-256 instead.

Why you compare fingerprints out of band

Suppose a colleague sends you their key by email, or you find it on a server. An attacker who controls that channel could have swapped in a key of their own with the same name and address. Encryption would still work, perfectly, for the attacker. The defence is to get the fingerprint by some other route the attacker is unlikely to control as well: read aloud over the phone, printed on a card handed over in person, shown on a slide at a talk. If the two strings match, the key you hold is the key they hold.

That is why fingerprints are usually printed in groups of four hex digits. Ten groups for a version 4 key can be read aloud and compared without losing your place. RFC 9580 is frank that people are bad at comparing long random strings, and it asks software to prefer comparing fingerprints by machine where it can. The tool therefore lets you paste the fingerprint the owner gave you and compares every digit for you, while still showing the groups for the phone call.

The old answer to the same problem was the web of trust. People signed each other’s keys after checking identity, often at key signing parties, and software counted how many trusted introducers vouched for a key. It asks a lot, including meeting in person to check identity, and it brought its own trouble: a key heavy with signatures reveals who knows whom. A verified fingerprint from the owner is simpler and does not depend on strangers.

What keyservers do, and what they cannot vouch for

A keyserver is a public directory of keys. The first web-based one was written at MIT in the 1990s, and for many years the main network was a pool of servers that copied every upload to each other and made deletion deliberately hard. That design was meant to resist censorship. It also meant that nothing checked who owned the name and address on a key, and that personal data, once uploaded, could not be taken down. After a spamming attack in 2019 and a run of data protection requests it could not handle, the old pool shut down in 2021.

keys.openpgp.org, run as a community effort on the Hagrid software, takes a different line. It splits a key into identity and non-identity parts. The non-identity part, meaning the key material, creation time, expiry and revocation status, is stored and given to anyone once it passes a cryptographic integrity check. A user ID is published only after the owner confirms the email address by answering a message sent to it. Its privacy policy says enumeration of addresses is not possible, that addresses are searchable only by exact match, and that request logs are kept for 30 days with IP addresses anonymised.

The consequences show up as soon as you look a key up. By email, the server returns a key only if its owner opted in, and lookups by address are limited to 1 per minute with a small burst allowance. By fingerprint or key ID, the limit is five a second, and the key that comes back may carry no user ID at all, because nobody confirmed one. That is not damage: the key still works for checking signatures and encrypting, and the confirmed address, when there is one, is the only identity the server stands behind.

Even then, the confirmation proves control of a mailbox at one moment, nothing more. The server’s own FAQ says it is meant for distribution and discovery, not as a certification authority. Someone who can read your mail could confirm a key in your name. The fingerprint check is still the step that matters.

Expiry, revocation and the newest self-signature

Much of what a key says about itself lives in self-signatures. A version 4 key normally records its usage flags and its expiry in the signature that binds the primary user ID, while a version 6 key must carry a direct key signature that does the same job. Expiry is stored as a number of seconds after creation, not as a date. When there are several self-signatures, the standard says to use the newest valid one, which is how an owner extends a key that is about to lapse. The tool follows that rule and says which signature it used.

Revocation is stronger than expiry. A key revocation signature says the key must not be used again, and it carries a reason: superseded, retired, compromised, or none given. RFC 9580 points out that a compromised key casts doubt on every signature it ever made, while a retired one does not. Subkeys and user IDs can be revoked on their own. keys.openpgp.org passes key revocations along with the rest of the technical data, but it does not republish revoked identities, so a user ID that quietly disappears may be the only sign you get.

A signature only counts if it verifies. The tool checks each self-signature with the cryptography built into your browser, the Web Crypto interface, which handles RSA, ECDSA on the NIST curves and, in current browsers, Ed25519. Ed25519 in OpenPGP signs a hash of the data rather than the data itself, a detail RFC 9580 spells out. Where the browser lacks an algorithm, such as DSA or the brainpool curves, the tool says “not verified” in plain words rather than guessing.

Key size deserves a word too. NIST SP 800-131A asks for at least 112 bits of security for new signatures, which it states as an RSA modulus of 2048 bits or more, or an elliptic curve whose order is at least 224 bits. A 1024-bit RSA key is left for checking old signatures only. Every curve OpenPGP defines today clears the bar.

Older and newer key versions

Version 3 keys have been deprecated since 1998: their key IDs came straight from the RSA modulus and their fingerprints used MD5, both easy to abuse. Version 4 replaced them, and although RFC 9580 now deprecates version 4 as well, it tells software to keep accepting such keys. Version 6 adds a length field for the key material, salted signatures, SHA2-256 fingerprints and the native Ed25519 and X25519 formats, and it drops the checksum that version 4 armor used to carry. Some tools also write a version 5 format that RFC 9580 does not define; GnuPG made this page’s Ed448 test key that way. A careful reader reports such keys as unsupported rather than half-reading them.

None of this makes a key trustworthy by itself. A parser can tell you what the key claims, whether its own signatures hold, when it expires and whether its owner revoked it. It cannot tell you who is holding the secret half. That still takes a fingerprint, compared with the owner, by a route an attacker does not control.