Default GPG keyservers

An interesting conversation on the GPG mailing list that’s been ongoing for months. This info should help us choose a good set of default keyservers for user protection from fake signatures and/or DoS against the WoT.

security-misc /etc/skel/.gnupg/gpg.conf doesn’t define any currently.


The keystore trilemma is not yet solved. You can have two out of three
of decentralisation, universality, and abuse-resistance. WKD is
decentralised and abuse-resistant but is not universal.
is universal and abuse-resistant but highly centralised (and
functionally limited). Synchronising keyservers (SKS and Hockeypuck) are
decentralised and universal but abuse-prone.

Signature attestations will help tackle many of the abuse (and
functional limitation) issues, if we can get them standardised in a
future openpgp update (rfc4880tris?). But we will probably have to live
with more than one system for the foreseeable future, given the
different compromises required.


Hockeypuck is an alternative keyserver implementation written in Go. It’s being extended to verify sigs to stop key spam.

Here are the hockeypuck servers I could find, all synchronizing properly and apparently exchanging data (minus the unwanted packets) with the SKS servers that are synchronized:

Staying updated:

A dev put together a live graph classifying keyserver types and status. This could serve as a source for new entries in case the list becomes obsolete with time.

It also hosts graphs at:


What is universality?

If I understand that right, then Hockeypuck is not not abuse resistant, hence the same mess that lead to creation of gpg --recv-keys fails / no longer use keyservers for anything, hence unsuitable?

That would speak for new, fixed keyserver - or no default gpg keyserver.

I’m assuming that the same key can only be related to this particular email, on all servers.

They do have some protections as a WIP, not perfect but more than anything else outthere today and definitely better than SKS or relying on a single server.

1 Like

I Tested the servers on this list and only 4 work and they don’t even have your key on there. Only three recognize the Debian key so I don’t think making them default makes sense. Best to let devs decide on how users should fetch and verify their repo signing keys.

1 Like

Not sure we can blame them?

For example / new, fixed keyserver - (not in this forum thread) only people with access to my e-mail address / the domain name can upload. They’re using verification codes sent by e-mail. Not perfect, not against advanced adversaries but stopping most spam. Since it wasn’t done, they cannot be blamed.

Dunno how key upload works for key servers mentioned in this forum thread, how it would be resolved if a malicious key was uploaded and one wanted to replace it with a legitimate one etc.

I’d wait what kind of default emerges in Debian or similar or what gains traction. Until then, no default key server and users can opt-in to use one.

1 Like