Combating Networks of Forged OpenPGP Keys on Public Keyservers

Question

I recently noticed that someone has created an elaborate forgery of my OpenPGP key. Specifically, they orchestrated a short key (32-bit) fingerprint collision, and also forged additional keys to match those that signed my original identity (also orchestrating short fingerprint collisions):

(http://keys.gnupg.net:11371/pks/lookup?search=fourney&fingerprint=on&op=index)

---

Worryingly, this includes creating a forgery of the PGP Global Directory Verification Key,

(http://keys.gnupg.net:11371/pks/lookup?search=PGP+Global+Directory+Verification+Key&fingerprint=on&op=index)

together with a huge network of forged keys that sign its identity -- again, exploiting 32-bit fingerprint collisions:

(http://keys.gnupg.net:11371/pks/lookup?op=vindex&fingerprint=on&search=0xE1AA5DD7CA57AD7C)

This was a huge amount of work. Given that all these keys are revoked, I suspect this is the work of a security researcher who is out to prove a point.

However, given that GnuPG and these keys servers rely heavily on short fingerprints, I think this effectively breaks the entire public key server system.

My question is therefore twofold:

• What can be done to combat this problem, or reverse the damage?
• Can the public key server system still be trusted?

Answer 1

This seems like a key from the Evil 32 key set, which rebuilt the OpenPGP web of trust strong set using short key ID collisions to create awareness on how insecure relying on short key IDs is.

Can the public key server system still be trusted?

Sure it can, you just never should (and should have) trusted arbitrary keys on the key server network without building a trust path. Building short key ID collision just brought "fake key attacks" to a new level, but these have always been possible.

What can be done to combat this problem, or reverse the damage?

You cannot really do anything about that key. As all keys from the Evil 32 set have been revoked, at least that key should not be considered at all by others.

But of course, such a key set could be created at any time again! The idea behind the OpenPGP key server network does not provide any trust measures and should not be used for anything but exchanging keys. Trust must be established locally. Always distribute fingerprints or at least long key IDs, and educate your peers about the issue as necessary. Exchange certifications on your real key, for example by joining key signing parties, to enable you and others finding proper trust paths to and from your own key.

However, given that GnuPG and these keys servers rely heavily on short fingerprints, I think this effectively breaks the entire public key server system.

Neither of those rely on short key IDs at all, unless the user makes it to do so. GnuPG has a debatable default of printing short key IDs in overviews, though (which can be changed by using the keyid-format option (from man gpg):

--keyid-format none|short|0xshort|long|0xlong
   Select  how  to  display key IDs.  "none" does not show the key ID at all but
   shows the fingerprint in a separate line.  "short" is the traditional 8-char‐
   acter key ID.  "long" is the more accurate (but less convenient) 16-character
   key ID.  Add an "0x" to either to include an "0x" at the beginning of the key
   ID, as in 0x99242560.  Note that this option is ignored if the option --with-
   colons is used.