Five months ago, we launched this service. And just today, we have reached a remarkable milestone:
Thanks to everyone using this service! And thanks especially to those who have provided us with feedback, translations, or even code contributions!
A few updates on things we've been working on:
If you would like to see keys.openpgp.org translated into your native language, please join the translation team over on Transifex. We would appreciate help especially for Russian, Italian, Polish and Dutch.
That's all, keeping this one short! 👍️
It has been three months now since we launched keys.openpgp.org. We are happy to report: It has been a resounding success! 🥳
The keys.openpgp.org keyserver has been received very well by users, and clients are adopting it rapidly. It is now used by default in GPGTools, Enigmail, OpenKeychain, GPGSync, Debian, NixOS, and others. Many tutorials have also been updated, pointing users our way.
At the time of writing, more than 70.000 email addresses have been verified.
A special shout-out here goes to GPGTools for macOS. They implemented the update process so smoothly, the number of verified addresses completely exploded when they released their update.
There is not a lot to report operationally, and no news is good news in this case! Since launch, there was nearly zero downtime, only a single bug came up that briefly caused issues during upload, and support volume has been comfortably low.
Our traffic is currently at about ten requests per second (more during the day, less on the weekend), and we delivered roughly 100.000 emails in the last month. No sweat.
We made several small operational improvements including deployment of DNSSEC, implementing some rate-limiting, nailing down our content security policy headers, and enabling single-hop mode on our Tor Onion Service. You can find a more complete list here.
One improvement that deserves special mention is MTA-STS, which improves the security of outgoing emails.
While HTTPS is deployed fairly universally these days, that sadly isn't the case for email. Many servers don't do encryption at all, or use a self-signed certificate instead of a proper one (e.g. from Let's Encrypt). But delivery failures upset customers more than reduced security, and many emails are still delivered without encryption.
With MTA-STS, domain operators can indicate (via HTTPS) that their email server does support encryption. When a secure connection can't be established to such a server, message delivery will be postponed or eventually bounce, instead of proceeding insecurely.
This is extremely useful for service like keys.openpgp.org. If encryption isn't reliable, attackers can intercept verification emails relatively easily. But for providers who have MTA-STS deployed, we can be sure that every message is delivered securely, and to the right server.
You can run a check to find out whether your email provider supports MTA-STS. If they don't, please drop them a message and tell them to step up their security game!
We are working on two features:
The first is localization. Most people do not speak English, but so far that is the only language we support. To make this service more accessible, we are working with the OTF's Localization Lab to make the website and outgoing emails available in several more languages.
The second is to bring back third-party signatures. As mentioned in our FAQ, we currently don't support these due to spam and potential for abuse. The idea is to require cross-signatures, which allow each key to choose for itself which signatures from other people it wants to distribute. Despite this extra step, this is fairly compatible with existing software. It also nicely stays out of the way of users who don't care about signatures.
Although work is in progress for both of those features, neither have a planned time of release yet.
Regarding the "no user ID" issue with GnuPG (mentioned in our last news post and our FAQ), a patch that fixes this problem is now carried by Debian, as well as GPGTools for macOS. GnuPG upstream has not merged the patch so far.
That's it! Thanks for your interest! 👋
We created keys.openpgp.org to provide an alternative to the SKS Keyserver pool, which is the default in many applications today. This distributed network of keyservers has been struggling with abuse, performance, as well as privacy issues, and more recently also GDPR compliance questions. Kristian Fiskerstrand has done a stellar job maintaining the pool for more than ten years, but at this point development activity seems to have mostly ceased.
We thought it time to consider a fresh approach to solve these problems.
The keys.openpgp.org keyserver splits up identity and non-identity information in keys. You can find more details on our about page: The gist is that non-identity information (keys, revocations, and so on) is freely distributed, while identity information is only distributed with consent that can also be revoked at any time.
If a new key is verified for some email address, it will replace the previous one. This way, every email address is only associated with a single key at most. It can also be removed from the listing at any time by the owner of the address. This is very useful for key discovery: if a search by email address returns a key, it means this is the single key that is currently valid for the searched email address.
The keys.openpgp.org keysever will receive first-party support in upcoming releases of Enigmail for Thunderbird, as well as OpenKeychain on Android. This means users of those implementations will benefit from the faster response times, and improved key discovery by email address. We hope that this will also give us some momentum to build this project into a bigger community effort.
Privacy-preserving techniques in keyservers are still new, and sadly there are still a few compatibility issues caused by splitting out identity information.
In particular, when GnuPG (as of this writing, version 2.2.16) encounters an OpenPGP key without identities, it throws an error "no user ID" and does not process new non-identity information (like revocation certificates) even if it is cryptographically valid. We are actively engaged in providing fixes for these issues.
Privacy-preserving techniques in keyservers are still new, and we have more ideas for reducing the metadata. But for now, our plan is only to keep keys.openpgp.org reliable and fast 🐇, fix any upcoming bugs 🐞, and listen to feedback from the community. 👂
For more info, head on over to our about page and FAQ pages. You can get started right away by uploading your your key! Beyond that there is more cool stuff to discover, like our API, and an Onion Service!