Real PGP Short‑ID Collisions Expose Fake Keys and MITM Risks – Use Full Fingerprints

PGP Short‑ID Collision Attacks

Since June 2023 authentic short‑ID collisions have been observed on the Internet. An attacker can generate a counterfeit OpenPGP key whose 8‑byte short identifier, user name, e‑mail address, and even the trust signatures are identical to those of a legitimate key. Because the short ID is the only identifier shown by many user interfaces, the fake key can be accepted as the genuine one, enabling man‑in‑the‑middle attacks and the creation of a parallel trust network.

Concrete Examples

Fake: 0F6A 1465 32D8 69AE E438 F74B 6211 AA3B [0041 1886] Real: ABAF 11C6 5A29 70B1 30AB E3C4 79BE 3E43 [0041 1886] Fake: 497C 48CE 16B9 26E9 3F49 6301 2736 5DEA [6092 693E] Real: 647F 2865 4894 E3BD 4571 99BE 38DB BDC8 [6092 693E]

The two pairs correspond to forged keys for high‑profile developers Linus Torvalds and Greg Kroah‑Hartman. In each case the short ID (the eight‑byte value shown in square brackets) collides, while the full 20‑byte fingerprint differs.

Why Extending Short IDs Does Not Fix the Problem

Developer Gunnar Wolf points out that the fundamental issue is the reliance on a truncated portion of the full fingerprint as an identifier. Even if the short ID length were increased (e.g., to 12 bytes), the collision space would still be large enough for an attacker to find a matching fragment, because the identifier is not cryptographically unique.

Recommended Mitigations

Display the complete fingerprint. User interfaces should show the full 20‑byte (or longer, e.g., SHA‑256) fingerprint for every key.

Hide identifiers entirely. When verification can be performed automatically (e.g., via gpg --verify), UI should omit any truncated ID to avoid giving a false sense of security.

Enforce full‑fingerprint verification in workflows. Example command to list a key with its full fingerprint: gpg --list-keys --with-fingerprint --with-colons Update software libraries. Applications that accept short IDs (e.g., older versions of GnuPG, email clients, or keyservers) must be patched to require full fingerprints or to reject ambiguous identifiers.

Adopting these practices removes the ambiguity that enables short‑ID collisions and restores confidence in the OpenPGP trust model.