SKS Keyserver Network Under Attack

Alyssa Ross hi at alyssa.is
Mon Jul 1 00:23:11 CEST 2019


> Third-party signatures from locally unknown certificates are arguably
> not so useful, so how about using ?--keyserver-options import-clean??
> (Or even making it the default behavior?)  Of course it's not perfect as
> it still clutters network traffic and gpg(1) needs to clean up the mess
> client-side (which is slow and CPU expensive), but at least it mitigates
> the DoS attack: it doesn't prevent keyring updates, and limits the bloat
> on disk.

Alas, this doesn't fully mitigate the issue, because it's not exactly
difficult to get a key into somebody's keyring, especially with the
existence of the auto-key-retrieve option. All I would have to do would
be to sign the key of somebody in the strong set lots of times with
the same key, and then send you an email signed by me, and an email with
a body signed by the key I was attacking (I could find some sort of
statement signed by that key online somewhere). Alternatively, I could
construct a Git repository that would load the keys into your keychain
in the correct order when you examined the commit signatures if I could
find a commit signed by my victim somewhere. I'm sure it's easy enough
to get a public key imported even without auto-key-retrieve, too. I
imagine there are MUAs that would import a key attached to a message,
maybe.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190630/d5683301/attachment-0001.sig>


More information about the Gnupg-users mailing list