[tor-project] PSA: flood attack against OpenPGP certificates underway
anarcat at torproject.org
Fri Jun 28 19:17:56 UTC 2019
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:
... 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`:
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
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
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 at 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.
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
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
torproject.org system administration
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 487 bytes
Desc: not available
More information about the tor-project