32-bit Short-ID permanently discredited
free@turing ~$ gpg --keyserver pgp.mit.edu --recv-keys 10000001 gpg: requesting key 10000001 from hkp server pgp.mit.edu gpg: key 10000001: public key "Linus Torvalds" imported gpg: key 10000001: public key "Linus Torvalds" imported gpg: Total number processed: 2 gpg: imported: 2 (RSA: 2)
It has long been known that PGP is vulnerable to attacks against a short identifier (short-ID). It is relatively easy to generate a pair of GnuPG-compatible 4096-bit RSA keys with a predefined short (32-bit) short-ID, owner name, and email address. The collision search procedure takes literally 10-20 minutes on a regular computer, which has been demonstrated repeatedly. On a modern GPU, it takes
4 seconds when using the
Scallion program.
Previously, the attack was considered purely theoretically, but since June 2016, developers
began to report real cases of falsification of their short identifiers - fake keys were placed on servers of cryptographic keys. And now
it came to Linus Torvalds and the leading developers of the Linux kernel.
Among the victims - Linus Torvalds, Greg Kroah-Hartman (Greg Kroah-Hartman) and other well-known developers.
Search result for 0x00411886:
https://pgp.mit.edu/pks/lookup?search=0x00411886&op=indexFake Linus Torvalds: 0F6A 1465 32D8 69AE E438 F74B 6211 AA3B [0041 1886]
This Linus Torvalds: ABAF 11C6 5A29 70B1 30AB E3C4 79BE 3E43 [0041 1886]
')
Search result for 0x6092693E:
pgp.mit.edu/pks/lookup?search=0x6092693E&op=indexFake Greg Kroa-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]
In the first case, the short identifier 0041 1886 matches the name and email address (Linus Torvalds <torvalds@linux-foundation.org>).
In the second case, the short identifier is 6092 693E (Greg Kroah-Hartman (Linux kernel stable release signing key) <greg@kroah.com>).
Theoretically, a collision can be found not only for a 32-bit one, but
even for a 64-bit short identifier . Let not in a few seconds, but in a few days or weeks on a regular GPU. Although, on an ASIC cluster, this will be an order of magnitude faster. Say, modern ASIC Bitcoin miners work with a hashrate of 14 terahesh per second. And if you set such a goal and use the cluster?
It is believed that all the fake keys fell on the cryptographic key server from the
Evil 32 database. The base of cloned keys (about 24 thousand) has long been accumulating there. Apparently, recently some joker decided to upload them to a public server of cryptographic keys.
Even if the guys with Evil 32 delete their base of fake keys, anyone can repeat the attack.
The conclusion is obvious: it is better to stop using the Short-ID at all, not to specify them anywhere, but to use only the full fingerprints of the public key. Moreover, the latest version of GPG 2.1 already shows full prints by default.