Without looking very deep, I quickly stumbled on 4 keys that were attacked last month:

Date(s)

Total Signatures

File Size (ASC)

Key UID

Key Fingerprint

2019-06-17, 06-18

54,600

22 MB

Daniel Kahn Gillmor

0xC4BC2DDB38CCE96485EBE9C2F20691179038E5C6

2019-06-19

149,100

60 MB

Robert J. Hansen

0xCC11BE7CBBED77B120F37B011DCBDC01B44427C7

2019-06-26, 06-27

84,366

34 MB

Micah Lee

0x927F419D7EC82C2F149C1BD1403C2657CD994F73

2019-06-30

121,000

25 MB

Tor Browser Developers (signing key)

0xEF6E286DDA85EA2A4BA7DE684E2C6E8793298290

The Problem

If your GnuPG client or thunderbird's enigmail is configured to automatically `--refresh-keys`, then you could also automatically break your GnuPG install if it downloads one of these poisoned certificates into your keyring.

Note that this problem is further exacerbated by the fact that keyservers by design do not delete keys. Though this introduces obvious vulnerabilities, it was a decision made to make the network resilient to government tampering & censorship.

Personally, I noticed this issue when my email stopped working. Debugging thunderbird & enigmail pointed me to issues with PeP, but--as I was debugging--I noticed that `gpg` was hanging on `removing stale lockfile`. This was because thunderbird was already running, and it was hanging on the poisoned certificate.

If the above command takes longer than a few seconds to run, then you have a problem. Give it 20 minutes or so, and you'll see problematic keys at the bottom. Anything with 8 digits (>10 MB) is a red flag.

ⓘ Note: In the example above, we see that the public key with id = `F20691179038E5C6` has a size of `16934647` bytes = 16M. This is our poisoned key.

The commands that follow in this article use this `keyid` (`F20691179038E5C6`) to manipulate the keyring. You should replace this string in the commands below with the corresponding `keyid` found in the command above on your machine.

2. Exporting the poisoned key

Now that we've identified the poisoned key, let's export it for safe keeping before we delete it.

After a few minutes, the command will finish, and you should have a file named `pubkey.asc` with the contents of the poisoned public key in it. Note that this ASCII armored file containing exactly one public key is 22M!

3. Deleting the poisoned key

Now that we have a safe backup of the poisoned key on disk, let's delete it from our keyring.

5. Updating your GnuPG config

As Robert J. Hansen (whoose pgp key was spammed with 149,100 signatures on 2019-06-19) pointed out in their excellent comprehensive gist about this issue, you can prevent your gpg client from breaking itself by:

Removing any lines that start with `keyserver` in your `gpg.conf` file and

Updating `dirmngr.conf` so that it has only one keyserver: `keyserver hkps://keys.openpgp.org`

That `keys.openpgp.org` keyserver is a new experimental server (interestingly, it went live just weeks before these poisoned certificates were uploaded) that is more resistant to these attacks. Note that the certificates it serves entirely lack third party signatures, and it also strips the UID packets from the key unless a user explicitly opts-in.

6. Updating your MUA config

Update 2019-07-16: Enigmail changed their default keyserver to `keys.openpgp.org` in v2.0.12, so updating engimail >= this version is preferred to disabling `keyRefershOn` as described below, if possible. (ty Wiktor)

Firefox Advanced Config Editor

You may also need to update your MUA. For example, enigmail in thunderbird may also be configured to update the keys in your keyring.

The mitigation is not working for me. GnuPG is still trying to access subkeys.pgp.net after I've removed the keyserver setting in gpg.conf, modified dirmngr.conf to include `keyserver hkps://keys.openpgp.org`, restarted dirmngr, and re-ran `gpg2 --refresh-keys`.