You can summarize whatever you like, but what's the actual problem here? From your same link, a comment:

This isn't nearly the issue you claim, and not an attack at all. It's well-known, and people have created 32-bit collisions for probably about 20 years now. However, even going back to PGP's early days, the software dealt with 64-bit key ids, and software in general does the right thing.

Stephen Paul Weber above points out correctly that if you ever get stuck with with the wrong key, signatures won't be valid, encryption won't work, etc. As he says, it can cause nothing worse than confusion.

In the example you give yourself, GPG does the correct thing! There are now two keys on the MIT key server with the same truncated key id, but they have different 64-bit key IDs. GPG goes and gets both keys, which is exactly what it should be doing.

If you create a key with a 32-bit collision to PRZ's, Werner's, mine, or whomever's, nothing bad will happen. You cannot forge a signature, you cannot mis-encrypt. Sorry, you're wrong on that. Nothing bad will happen. If you don't believe me, try it.

Lastly, both RFC 2440 and RFC 4480 say:

A Key ID is an eight-octet scalar that identifies a key. Implementations SHOULD NOT assume that Key IDs are unique.

and

Note that it is possible for there to be collisions of Key IDs -- two different keys with the same Key ID. Note that there is a much smaller, but still non-zero, probability that two different keys have the same fingerprint.

Yes, you're right that the user experience of a command-line program that allows you to type in a subset of a 64-bit number can lead to confusion -- you got led there. But it's not an attack and not a security problem.

Regards,
Jon, OpenPGP co-author and co-founder of PGP.

Short key ID collisions.

Yes, I understood that your *concern* is about short key ID collisions. But what *problem* does this cause, in practice? This is a "display bug", as far as I can tell.

I would like to note that when I wrote the previous reply, the reply before only was a single line.

The connection to the key server is not secure so it can be man-in-the-middled and I could get a fake key with the same short ID, only. Right?
Also, many users of GPG have not yet heard of the problem and could use help from pacman-key by not being presented short key IDs.

> The connection to the key server is not secure so it can be man-in-the-middled and I could get a fake key with the same short ID, only. Right?
Asking for a non-unique short ID will lead to GPG retrieving all keys with that short ID. If your connection is MITM'd, the contents of the keyserver are irrelevant, as the attacker can inject any arbitrary response.

That's why the user could use help avoiding short key IDs. MITMing my connection without notice will be harder then. Not presenting short keys to him or her would help in that regard.

Anyway... this is not a pacman-key issue. That command is a wrapper around a GPG call. Talk to the GPG developers.

There is GPG parameter `--keyid-format short|0xshort|long|0xlong`. Is that being used at all places possible already?

It could be added but what is the point. From the quote above:

"If you create a key with a 32-bit collision to PRZ's, Werner's, mine, or whomever's, nothing bad will happen. You cannot forge a signature, you cannot mis-encrypt. Sorry, you're wrong on that. Nothing bad will happen. If you don't believe me, try it."

So even if a MITM gives you a matching key, nothiing bad will happen.

Here's a patch. Please consider application. Thank you.

I am going to repeat my question - what is the point? At worst, you download two PGP keys when finding who owns a key. And why should pacman-key's display be any different that gnupg?

I will accept a patch that add the --keyid-format option to pacman-key and passes it on to the gpg command.