GnuPG — "SKS Keyserver Network Under Attack":

"If you fetch a poisoned certificate from the keyserver network, you will break your GnuPG installation."

"High-risk users should stop using the keyserver network immediately."

@infosechandbook It's too complicated for casual vandals and script-kiddies.
Who would have an interest in doing such a thing? Hmmm.

@gemlog @infosechandbook Three guesses of a certain agency, the first two don't count.

@infosechandbook " is a new experimental keyserver which is not part of the keyserver network and has some features which make it resistant to this sort of attack. It is not a drop-in replacement: it has some limitations (for instance, its search functionality is sharply constrained). However, once you make this change you will be able to run gpg --refresh-keys with confidence."

@infosechandbook And part of the problem is that an important software is written in #OCaml (according to Robert J. Hansen). #OpenPGP #GnuPG


The problem is that they are all competing drafts and aren't widely used:

– PKA (Public Key Association) by Werner Koch
– WKD/WKS (OpenPGP Web Key Directory) also by Koch is still an "informational draft"
– OPENPGPKEY (RFC 7929) is an experimental draft and requires a DNS server
– non-federated services like Keybase or

They all come with privacy issues due to the design of GPG and the web of trust is mostly dead.

PKA is obsolete. Here’s the comment from Werner Koch:

OPENPGPKEY sends requests and responses in the clear (because of DNS) and as far as I know GnuPG doesn’t even validate DNSSEC signatures:

WKD is a clear winner here as it reuses HTTPS (so it’s encrypted and authenticated by default). WKD is also the only method enabled by default in GnuPG and has the biggest adoption with clients (OpenKeychain, Mailpile, Enigmail, Gpg Outlook plugin, etc.) and servers (e.g. ProtonMail supports fetching their user keys using WKD).

For people interested in in-depth analysis of DNS vs WKD see this thread:

@infosechandbook @ilpianista
As well as alternatives to GPG:
- NeoPG
- SequoiaPGP
- opmsg
- minisign
- saltpack
- Keybase
- age (soon)


Temporary replacement can be till SKS gets stable fix/replacement.

@cypherpunk is not a viable replacement. There are a lot of important keys (i.e. distro keys, signing keys for other software, …) that simply don't fit into the keybase model.

Also replacing something decentralized with something centralized especially in this (*hehe*) key position is a really bad idea.

There are various alternatives to the official SKS keyserver implementation, not perfect, but definitely better, because organisations can run it themselves.


You are right, but I am at this moment not aware of any functional decentralized replacement for SKS.
Can you please be more specific, what did you have in mind?
Btw, I was concerned about journalists and activists who rely on SKS and something easy to use for key exchange.


Well, first of all, there is WKD, which, to be fair, is not a keyserver implementation by itself, but great for key exchange.

For keyserver implementations I'm thinking of things like the mailveleope keyserver, which isn't doing this background sync that SKS servers do, but at least self-hostable.

I would still prefer WKD to find wider adoption.


Thanks, didn't know of WKD till now. 😃
Mailvelope has been around for a while now but haven't seen much adoption from any community yet.
Hope we find some viable solutions.
Maybe now is the time for serious SKS improvement and rebranding.

@cypherpunk @infosechandbook theres already an experimental keyserver running that mitigates these issues. keybase doesnt have hkp access
Sign in to participate in the conversation
Mastodon is a microblogging site that federates with most instances on the Fediverse. Note: This instance will shut down on February 29th, 2020.