PGP Key Verification Deep Dive 2026: Fingerprints, Signatures, and Detecting Swapped Vendor Keys

A vendor’s PGP key can look perfectly legitimate and still be the wrong key. The armor may be intact, the email address may match, and the website may display the expected public key. None of that proves you received the authentic key.

The useful question is narrower: can you prove that this exact key belongs to the party you intend to contact, and can you detect a later substitution? That requires fingerprints, signatures, independent channels, and a record of key history. This is research only. Do not use these procedures to access markets, send funds, or conduct transactions.

What PGP actually proves

PGP performs two separate jobs. Encryption uses the recipient’s public key so that only the corresponding private key can decrypt the message. Signing uses the sender’s private key, allowing anyone with the public key to check that the message was signed by the matching secret key and was not altered afterward.

That distinction matters. A valid signature proves control of a private key. It does not, by itself, prove who controls that key. If an attacker convinces you to install the attacker’s public key, messages signed by that key can verify cleanly while still coming from the wrong party.

The identity problem is solved outside the cryptographic operation. You compare the key’s fingerprint with a fingerprint obtained through a trusted, independent channel. KeychainPGP’s beginner documentation describes the fingerprint as the short identifier used to check whether a public key is the one you expect. That comparison is the defense against a man-in-the-middle substitution.

Fingerprint first, key block second

ASCII armor is only a text representation. A block beginning with —–BEGIN PGP PUBLIC KEY BLOCK—– can be copied through email, chat, or a web form, but the visual format tells you nothing about authenticity. An attacker can generate a different key and wrap it in identical armor.

Import the key into a clean, controlled keyring, then inspect its full fingerprint. Do not rely on a short key ID, the last few hexadecimal characters, a username, or an email address. Those fields are convenient labels. The full fingerprint is the value you compare.

• Display the fingerprint: use your OpenPGP client’s key listing command with fingerprint output enabled.
• Read the complete value: avoid comparing only the final eight or sixteen characters.
• Compare out of band: use a previously trusted document, an authenticated conversation, or a voice or in-person comparison.
• Record the result: save the fingerprint, date, source, and any stated expiration or revocation information.

A practical GnuPG workflow is to import the candidate public key into a separate research keyring, then run a fingerprint listing against that keyring. Keeping it separate prevents an unverified key from becoming mixed with keys you already trust. The exact commands vary by operating system, but the relevant GnuPG operations are key import, fingerprint listing, signature verification, and key export.

Do not paste a private key into a website or send it to anyone. The private key creates signatures and decrypts messages. The public key is the material intended for distribution. The distinction is basic, but fake support pages and rushed operators regularly exploit confusion between the two.

How to obtain a trustworthy comparison value

One published fingerprint is not automatically an independent confirmation. If the key and the fingerprint appear on the same compromised page, an attacker can replace both. You have gained consistency, not authentication.

Look for a second channel that was established before the suspected compromise. Examples include a previously archived statement, a signed announcement from an older verified key, or a direct conversation using a channel whose identity you already validated. A fingerprint read over a voice call is useful because the attacker would need to control both the key distribution point and that separate conversation.

Independence matters more than quantity. Five copies of the same fingerprint on mirrors do not outweigh one reliable, previously verified record. Treat directories and aggregators as discovery sources, not as the final authority. A server compromise can replace every key displayed by that server at once.

Never treat a browser’s HTTPS connection as proof that the displayed PGP key belongs to the intended vendor. Transport security can protect the connection while the site owner, administrator account, hosting account, or content pipeline is compromised.

Verify signatures on statements, not just keys

After establishing the fingerprint, verify an actual signed statement. A vendor or administrator may publish a detached signature alongside a text file, or provide a clear-signed message. Your OpenPGP tool checks whether the signature matches the exact content you downloaded.

Keep the original files. Verification is meaningful only if you know what was signed. Save the statement, the signature, the public key used, the fingerprint shown by your tool, and the date of collection. Hashes can help prove that your local copy did not change, although a hash published by the same untrusted source does not establish origin.

• Import the candidate public key into an isolated keyring.
• Inspect the full fingerprint before trusting any signature result.
• Verify the detached signature against the exact downloaded statement.
• Read the verifier output carefully. A mathematically good signature and a trusted identity are separate conclusions.
• Compare the signing key fingerprint with your independently obtained reference.

A message stating “Good signature” is not a green light by itself. It means the content matches a signature made by the private key corresponding to the public key you supplied. If that public key was swapped, the cryptographic check can succeed while the identity check fails.

Detecting a swapped vendor key

The obvious replacement

The simplest attack presents a new key with a familiar name and email address. Your software may show a friendly user ID, but that user ID is data attached to the key. It is not a certificate from a central authority.

The detection method is direct: compare the new key’s full fingerprint with your recorded baseline. Any difference is a key change, even if the name, email, comment, and profile picture are identical. Stop there until the change is explained through an independent channel.

The replacement with a copied identity

An attacker can copy the original key’s user ID onto a new key. This is why searching for a name or email address is weak verification. Inspect the fingerprint, creation date, expiration, revocation status, and associated subkeys.

A changed creation date is a strong warning. So is a newly generated key that appears without a signed transition statement or a credible explanation. Do not infer legitimacy from a newer algorithm or a more modern-looking key. Newer is not the same as authentic.

The valid key with altered content

Key verification also has limits. If an attacker compromises the legitimate private key, signatures may verify correctly. The key is authentic, but the message may still be malicious or unauthorized. Likewise, an administrator who legitimately controls the key could sign a fraudulent announcement.

This is why signed content needs context. Compare announcements with previous behavior, inspect unexpected changes, and treat urgent requests for credentials, payments, or software as suspicious. PGP confirms authorship by key control and content integrity. It does not certify the author’s judgment.

Subkeys, expiration, and revocation

OpenPGP keys can contain a primary key and separate signing or encryption subkeys. A signature may therefore show a subkey fingerprint rather than the primary key fingerprint you recorded. That is not automatically a swap.

Inspect the key’s relationship data. Confirm that the signing subkey is bound to the primary key and that the primary key fingerprint matches your trusted record. A new subkey under the same verified primary key can be a normal maintenance event. A new primary key is a more serious identity change.

Expiration is another source of confusion. An expired key should not be treated as current merely because old signatures still verify. Revocation requires greater caution. A revocation certificate is designed to tell software that a key should no longer be trusted, but you still need to determine whether the revocation came from the legitimate key holder or from a manipulated keyring.

Keep historical records instead of deleting old keys. A key that was valid for an earlier statement may be useful for checking an archive, while being unsuitable for new communication. Your notes should distinguish “verified at this date” from “currently trusted.”

A compact verification record

For each vendor identity under research, maintain a small evidence table. Record the full primary fingerprint, known signing subkeys, user IDs, creation and expiration details, revocation observations, and every independent source used for comparison.

• First observed: date and source.
• Fingerprint: the full value, copied from your local tool.
• Statement: exact filename or text description.
• Signature result: valid or invalid, including the signing key.
• Independent confirmation: how the fingerprint was checked.
• Change history: key rotation, new subkey, expiry, or revocation.

Take screenshots only as supplementary evidence. Prefer exported key material and the original signed files, because screenshots omit details and can be edited. Store the evidence offline or in a location protected from later tampering.

Common mistakes that defeat the process

• Trusting a short key ID: it is not a full identity check.
• Using the same page for key and fingerprint: one compromise can replace both.
• Confusing encryption with authentication: encrypted content is not necessarily signed content.
• Ignoring verifier warnings: a signature can be cryptographically valid while the key remains untrusted.
• Accepting an unexplained rotation: require a signed transition or independent confirmation.
• Using an online tool with sensitive private material: browser tools may run locally, but verify that claim and never expose a private key unnecessarily.

The reliable pattern is repetitive by design: obtain the key, inspect the full fingerprint, confirm it through an independent channel, verify signed statements, and preserve the evidence. If the fingerprint changes without a convincing continuity proof, assume the identity is unverified. A working signature is only one part of that conclusion.