Hi,
Since the Tor project uses OpenPGP and GnuPG extensively in its operations, I figured it was important to let the community know of an ongoing attack against the keyserver infrastructure and GnuPG. The longer story is available on dkg's blog here:
https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html
... but a summary is that at least two prominent OpenPGP users have seen their public key flooded with thousands of signatures, to the point where their keys are now completely unusable.
I recommend you consider taking the following immediate actions, either:
1. in the short term, disable automated key refreshes on your keyring (either through Parcimonie or manual scripts calling `gpg --refresh` in some other way), or;
2. switch to the new keys.openpgp.org keyserver, by setting the following in your `gpg.conf`:
keyserver hkps://keys.openpgp.org/
The first action should only be used in the short term, to allow you to evaluate your options. It might mitigate the problem (unless you somehow allow the nasty keys to enter your keyring some other way), but it will mean you will not be aware of the precious revocation certificates users post when their key is compromised, so it's not an acceptable solution in any way.
The second action has been tested as mitigating the problem, but has several downsides as well:
a. it does not store UIDs unless they are verified and asked for explicitly (workaround: keys can be shipped in-band with Autocrypt or found through other mechanisms like WKD, Web Key Discovery)
b. it does not store UID signatures at all, which will impact the web of trust (workaround: same as point a, and you should send signed keys by email anyways to verify ownership of the UID, using tools like caff, pius, gnome-keysign or monkeysign)
c. GnuPG cannot read refresh keys from keys.openpgp.org (workaround: use the custom patch shipped in Debian experimental, see Debian bug #930665)
d. it does not currently receive updates from the SKS pool (workaround: upload key updates to keys.openpgp.org directly as well as the SKS pool)
Note that keys.openpgp.org has been seeded with the global SKS keyserver datastore, so it contains all the keys you would expect to be present on the latter, except they are sanitized to avoid this problem.
I encourage users to:
1. upload their keys to the keys.openpgp.org keyserver
2. either switch to keys.openpgp.org by default or carefully review their key fetching configuration to make sure it is not vulnerable to this attack
3. review dkg's article and make sure your own keys are not affected by this problem
If you have fetched an hostile key and GnuPG has become unusable, you can recover by deleting the key with:
gpg --delete-key C4BC2DDB38CCE96485EBE9C2F20691179038E5C6
Note that this may take anywhere from 20 minutes to an hour.
And then fetch dkg's key via WKD:
gpg --locate-keys dkg@fifthhorseman.net
or his website, https://dkg.fifthhorseman.net/dkg-openpgp.key.
The other known key affected by this problem is Robert J, Hansen's key, with the fingerprint "CC11BE7CBBED77B120F37B011DCBDC01B44427C7".
As far as I know, torproject.org infrastructure has not been affected in any way by this attack. We carefully monitor keys we allow in our keyring which should be sufficient to mitigate this attack.
A.
PS: to check if your key is affected *without* importing it into your keyring, you can use the following command:
FINGERPRINT=0x8DC901CE64146C048AD50FBB792152527B75921E # for example mine KEYSERVER="http://pool.sks-keyservers.net/" URL="$KEYSERVER/pks/lookup?op=get&search=$FINGERPRINT&options=mr&fingerprint=on&exact=on" curl -sSL "$URL"| gpg --list-packets | grep -c '^:signature packet:'
This counts the number of signatures on your key. A reasonable number is less or around a thousand. dkg's key has now around 55 000 signatures on his key, which (naturally) causes some trouble in all OpenPGP implementations.