Page MenuHome GnuPG

--recv-keys With Short IDs Is Insecure, Is Actively Being Attacked, And Should Be Removed Entirely
Closed, WontfixPublic


Somebody has created and deployed a tool which duplicates all of the important short IDs on the SKS keyservers. As a result, adding a key for many important projects - including in the way that their documentation instructions - now also adds "Totally Legit Signing Key <>".

You can read more about this here:

The tool to perform the collisions is here:

We got burned by this yesterday. Fortunately, the author is just trying to make a point and isn't doing anything malicious, but it would have been trivial for him or anybody else to cause serious damage.

Since it's trivial to spoof short IDs, I strongly recommend that this feature be disabled entirely and that only _full_ identifiers be used - even 64-bit identifiers are brute forceable for anybody with access to a well funded AWS account.

Event Timeline

Here's an example of a bad key:
which mimics the good key for R-CRAN:

Installing this with their official documentation would cause the malicious key to be installed (apt-key adv --keyserver --recv-keys E084DAB9).

Searching for "Totally Legit Signing Key <>" on Google reveals that there are people all over StackOverflow and GitHub who have been hit by this and not even realized it for other projects such as MongoDB and RVM.

werner claimed this task.
werner added a subscriber: werner.

This has always been the case and the worst thing which can happen is that (64 bit keyid clash) you might not be abale to import the "real" key. Keyserver's never promised to deliver the correct (in whatever sense) key, but are merely an anonymous and distributed stoarage systenms. This is why gpg does not trust a key by default but requires you to validate the key by other means (WoT, second channel, Web Key Directory).

Note also that gpg does not show the keyid anymore by default but instead shows the fingerprint and in addition in a way that it is easy to c+p.

This is not a topic for the bug tracker but should be discussed at gnupg-devel (for the nth time ;-).

You may indeed post to gnupg-devel if that helps to raise the attention of the Travis folks. If they need support we would be glad to help.