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.
@infosechandbook "keys.openpgp.org 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."
@ng0 keys.openpgp.org is not affected. It's written in #Rust. See: https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f @infosechandbook
We don't need keyservers anymore. People should setup WHK (https://wiki.gnupg.org/WKDHosting) or PKA (https://keyserver.mattrude.com/guides/public-key-association/).
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 keys.openpgp.org
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: https://lists.gnupg.org/pipermail/gnupg-users/2018-October/061034.html
OPENPGPKEY sends requests and responses in the clear (because of DNS) and as far as I know GnuPG doesn’t even validate DNSSEC signatures: https://lists.gnupg.org/pipermail/gnupg-users/2011-December/043361.html
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: https://github.com/openpgpjs/openpgpjs/issues/487
Some alternative I found today:
--- HocKeyPuck https://hockeypuck.github.io/
--- Hagrid/sequoya PGP https://sequoia-pgp.org/blog/2019/06/14/20190614-hagrid/
--- Skier https://github.com/SkierPGP/Skier
Temporary replacement can be keybase.io till SKS gets stable fix/replacement.
keybase.io 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.
mastodon.at is a microblogging site that federates with most instances on the Fediverse.