Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this community
https://sks-keyservers.net/ (Internet Archive snapshot) says
This service is deprecated. This means it is no longer maintained, and new HKPS certificates will not be issued. Service reliability should not be expected.
Update 2021-06-21: Due to even more GDPR takedown requests, the DNS records for the pool will no longer be provided at all.
Which keyservers can I use for gpg --keyserver "$keyserver1" --recv-key keyid that I can expect not will go away anytime soon?
Which keyservers can I use for
gpg --keyserver "$keyserver1" --recv-key keyidthat I can expect not will go away anytime soon?
The recommendation is to use keys.openpgp.org, however this keyserver only includes User IDs for keys whose owners have personally confirmed via email (basically eliminating large swaths of of the PGP ecosystem). It also does not include any 3rd party signatures on keys to mitigate the possibility of a "poisoned key" attack. As of December 2021, this is the default (if none is configured by the user) keyserver for GnuPG packaged by Debian since gnupg2 2.2.17-1 (released in 2019).
Personally, I'd recommend a Hockeypuck-based keyserver like keyserver.ubuntu.com, which isn't so limited (although it does strip 3rd party signatures). GnuPG has since changed this to the default as of versions 2.2.29 and 2.3.2.
keys.opengp.org and Hagrid but I haven't really researched Hockeypuck yet.
Dec 22, 2021 at 0:58
keyserver.ubuntu.com processes takedown requests from users, so it should not give up under GDPR pressure. Unlike keys.openpgp.org, it is comitted to keep peering with other servers. Finally, GnuPG now uses it by default.
Aug 22 at 7:01
keys.gnupg.net is also gone.
At least keyserver.ubuntu.com is still functional. I was able to use it from GnuPG only after adding a hkps:// prefix and a :443 suffix:
gpg2 --keyserver hkps://keyserver.ubuntu.com:443 --recv-keys XXXXXXXXXXXXXXXX
Notice that its web front-end and many others like https://pgp.key-server.io/ don't let you search for a key by its ID if you enter it like XXXXXXXXXXXXXXXX or XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX, but searching for 0xXXXXXXXXXXXXXXXX or 0xXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX works fine. It also works on https://pgp.mit.edu/, but the lookup is very slow there, and I couldn't get it working via GnuPG.
hkps:// schema or the :443 port number: either will suffice to use HKP over TLS. An advantage of HKPS is that it provides greater privacy and if the user is behind a corporate firewall, port 11371 could be blocked while 443 is unlikely to be.
Dec 22, 2021 at 0:37
pgp.mit.edu say that they do not process takedown requests, so it is not clear how they survive the GDPR, which is the concern in the OP's question. Also, they still use the SKS server software, which is told to be susceptible to certificate spamming attacks. Finally, they do not list gossip peers anymore, so they do not exchange keys with other servers.
Aug 22 at 7:13
Alternate public PGP key servers that support access via HKP (like SKS keyservers used to):
Access via other protocols that are supported by GnuPG:
Due to the fact that the SKS key servers were taken down due to GDPR relevant problems, we should be prepared that, on the long run, only verifying key servers remain available. Verifying key servers demand that the user verifies their email address before the PGP key is published.
(Parts of the information collected from PGP Key Retrieval)
SUMMARY
The Old
To add a little more detail to what not2savvy has written:
Basically, PGP Keyservers were running on SKS-Keyserver code written decades ago and unmaintained. They got hacked in June 2019 and got taken down permanently. For details, see this post by the maintainer of the GnuPG FAQ Robert J. Hansen SKS Keyserver Network Under Attack.
The New
Several new PGP Keyservers have been written since which implement the HKP Protocol
Verifying keyservers are new servers which verify the email addresses of uploaded keys, and are designed to be ”resistant to the abuse and privacy issues that plague old SKS Keyservers”.
I would suggest using verifying keyservers:
The Ubuntu keyserver below does not verify your keys email address but is a new maintained keyserver which may implement verification in the future.
I chose to use
