The Brewing Problem Of PGP Short-ID Collision Attacks
Written by Michael Larabel in Standards on 15 August 2016 at 03:00 PM EDT. 18 Comments
Using short PGP key IDs is proving to be insecure with real attacks having started this summer.

Phoronix reader Tom Li wrote in wishing to highlight the problem of using PGP short IDs and how real collision attacks are taking place. Here is the cleaned up and shortened version of what he sent in:

As you may know, PGP is a cryptography tool for encrypted secure communication, later, the protocol it uses became the OpenPGP standard, and eventually adopted in another free software project GnuPG, and widely use in the community.

It also has a well-known design flaw, that the last 8 digits of a public key's fingerprint is used to label the key, dispute the fact the full fingerprint is 160-bit, not 32-bit, and made collision attacks possible. 5 years ago, developer Asheesh Laroia generate a new PGP key with the same short-ID as the old one, effectively demonstrate such attacks are practically.

Real attacks, finally, started in June 2016. In June 3, developer Gunnar Wolf wrote an blog article titled "Stop it with those short PGP key IDs!".

Later, more and more developers found their fake keys with same names, emails, and even "same" fake signatures by more fake keys in the wild, on the keyservers. All these keys have same short-IDs, created by collision attacks, led with some discussions about the danger of short-IDs.

But many people were still unaware of this issue.

Now, it's worth to mention the issue again, since fake keys of Linus Torvalds, Greg Kroah-Hartman, and other kernel devs are found in the wild recently.

Search Result of 0x00411886:
Fake Linus Torvalds: 0F6A 1465 32D8 69AE E438 F74B 6211 AA3B [0041 1886]
Real Linus Torvalds: ABAF 11C6 5A29 70B1 30AB E3C4 79BE 3E43 [0041 1886]

Search Result of 0x6092693E:
Fake Greg Kroah-Hartman: 497C 48CE 16B9 26E9 3F49 6301 2736 5DEA [6092 693E]
Real Greg Kroah-Hartman: 647F 2865 4894 E3BD 4571 99BE 38DB BDC8 [6092 693E]

Gunnar Wolf suggested, that we shouldn't trust anything shorter than the fingerprint of the key, and merely switching from 32 to 64 bits is not a proper fix.
In short, that cutting a fingerprint in order to get a (32- or 64-bit) short key ID is the worst of all worlds, and we should rather target either always showing full fingerprints, or not showing it at all (and leaving all the crypto-checking bits to be done by the software, as comparing 160-bit strings is not natural for us humans).
- Gunnar Wolf
Related News
About The Author
Author picture

Michael Larabel is the principal author of and founded the site in 2004 with a focus on enriching the Linux hardware experience. Michael has written more than 20,000 articles covering the state of Linux hardware support, Linux performance, graphics drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and automated benchmarking software. He can be followed via Twitter or contacted via

Popular News This Week