We've noticed recently that the GPG keyservers have fake keys for some of the QEMU maintainers, which have keys which have been deliberately constructed to have collisions on the 32-bit "short ID" field which gpg shows you by default.
(Example: https://pgp.mit.edu/pks/lookup?op=vindex&search=0x14360CDE shows both my actual key and a fake.) It's been known for years that it's pretty easy to construct a key with whatever 32-bit short ID you like: http://www.asheesh.org/note/debian/short-key-ids-are-bad-news.html https://evil32.com/ so this is not a new or suddenly alarming attack on us specifically, but it seems like a good point to remind people that they need to be careful when using GPG in order not to be caught out by this: * whenever you're checking a PGP key, always check the full-length fingerprint, not the short ID or the not-so-short ID (eg output of gpg --fingerprint) * when you're interacting with anybody else doing PGP keysigning (especially if they are a PGP novice), emphasise that they need to check the full fingerprint at all stages * upgrade to a newer gpg which doesn't have the "only sends short IDs when asking keyservers for keys" bug * don't use 32-bit short ids in 'gpg --recv-keys' and similar command lines (and pay attention to the gpg output about how many keys it says it's downloaded) * add the following two lines to your .gnupg/gpg.conf: keyid-format 0xlong with-fingerprint so that gpg doesn't show you short-format IDs. Instead it will show 64-bit IDs and also fingerprints. 64-bit IDs can also collide so they are not a substitute for checking full fingerprints, but may be a helpful mollyguard against some of the junk in the public keyservers confusing you. * check whether you've already accidentally downloaded any keys with duplicate short-ids into your local keyring; I think this rune will work: gpg --list-keys | sed -ne 's/.*\([0-9A-F]\{8\}\).*$/\1/p' | uniq -d It is in general difficult to impossible to maintain a local keyring which only has intended keys in it without staging them via an intermediate temporary keyring, so the advice above about --recv-keys and setting the keyid-format is intended mainly to make it a little harder to make user errors when dealing with the junk in the public key servers. The major requirement is that you must always check the full fingerprint before signing a key. (I've sanity checked that none of the keys in my local keyring have dubious duplicates, which is what gets checked when doing signed merges into master. As a result of my recently making the config change suggested above you'll see that merge commits now quote the 64-bit long ID rather than the 32 bit short one and from now forward should also quote the full fingerprint.) thanks -- PMM
