Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Please add support for configuring external keyservers like mit.edu #236
Currently the CloudUrl setting is https://keys.whiteout.io. Do we or Can we have support for other keyservers? e.g. https://firstname.lastname@example.org
the reason we don't support the legacy key servers (yet) is:
that being said, we're all for making our stuff work with the legacy infrastructure, which is the reason we chose to do pgp in the first place. we haven't found the time to come up with a concept that is acceptable UX-wise and security-wise.
Yes, probably. We just haven't gotten to it.
Problem is that the key management is now no longer decentralized which might be security issue.
Thanks for your comments. I’ll answer your questions before diving deeper into key distribution.
Keybase provides better authentication of public keys than standard key servers, but they don't solve the problem of centralization that @parvez mentioned.
Well maybe. Keep in mind that a list of trusted key servers would still have to be maintained somewhere so the client could know which servers to query. Otherwise keys from organization A would not be available for organization B.
In terms of open sourcing our server components, we have currently only open sourced the client. Our thinking behind our open source strategy is described here:
Agreed. To put all these things into perspective, let me try to give an overview of the current landscape of key servers.
Some discussions for future reference
Problems with "legacy" key servers
Here's the wikipedia article about "legacy" key servers that lists the issues @felixhammerl mentioned:
The Google way
Google is doing some very interesting work on public key distribution that we are following closely. Here are some references from their wiki:
Key Distribution: https://github.com/google/end-to-end/wiki/Key-Distribution
Our current approach
All in all though, key distribution is a hard problem with no easy answers. We have chosen our simple key server solution under https://keys.whiteout.io as a first step mainly due to ease of use. Here is the current „protocol“:
While we know this is far from ideal, we believe it is much better than the status quo.
A potential future approach
We've discussed your suggestions yesterday and here is our suggestion on how we could provide support for „legacy“ key servers, while still providing the value add of our own key server.
Note: we already have invite to Whiteout functionality. But only in the reader for incoming mails.
What do you think? Does this make sense?
This is a really great discussion and answers the initial concerns I had regarding the whiteout key distribution implementation. Also thanks for making your stance publicly known.
I think the potential approach is good, but there is one issue:
This option runs the risk of a user simply choosing "yes" without actually verifying the key's fingerprint.
Perhaps you can implement something similar to Telegram's secret chat, where they can compare a QR code with one that's generated/stored in a trusted location?
I haven't fleshed out the entire answer to this problem, but this might be a good direction if we remember the end-user will likely not be as technical as most GPG users.
I've thought about this too. I'm a big fan of visualizations like the QR code when they improve the UX. Even my non-technical friends seem to understand that they should scan my QR code in Threema. Having said that, I'm not sure how the QR code will help in the case of fetching from an untrusted key server (unless the recipient has already given me a business card with the code or fingerprint, which is not a common practice among average users).
Another solution could be to let users upvote other user's keys to mark them as trustworthy. E.g. if several of my existing contacts have already upvoted the fetched PGP key for a new recipient, it would make it easier for me to decide to trust a new key.
Thanks for you open response. I truly appreciate what you guys have contributed to the Open Source Community. I understand the key management is one of the biggest challenge for PGP and your solution is the best currently.
It would be nice if you sync the keys from the public key servers (mark them as untrusted) and have the user select for the correct one when sending email. This way the user sending would be able to reach to users who are not using whiteout.io service as well.
Lesson learnt from Google Wave is to give users larger reach. If this is successful banks could be able to send and receive encrypted emails to their customers. I know its far fetched but thats what I envision.
Keybase is cool, but the system is just as closed as our current key server. What I'm suggesting is visualizing the OpenPGP Web of Trust similar to facebook's social graph like so:
This would reuse the data that is already stored on servers like pgp.mit.edu and display it with a new frontend so that average users could understand it. Nobody understands what it means to sign a PGP key, but everyone understands what a link between two people means. Users could "upvote" other user's identities by clicking on the link. This would sign the other user's PGP key in the background and upload the signature to a standard key server.
That's an awesome idea. I love the fact that you strive to make PGP easy to use for the average users. I love this concept. Can we start building a Proof of Concept for this visualization? I would love to contribute and could help in that.
How would you integrate this with whiteout?
@parvez no timeline on the Web Of Trust graph browser yet, but HKP server integration has been added in:
Basically our keys.whiteout.io keyserver will fetch keys from pgp.mit.edu in case no key is available and tag the key object with a source attribute. The sync works both way, so keys are uploaded to pgp.mit.edu after the email address has been verified on our server.
The client can't query pgp.mit.edu directly since the old pks servers don't support CORS headers required for cross-origin requests. That's why our key servers acts as a proxy.
The cool thing is that the user never has to worry about manually importing keys this way as keys will be fetched automatically during read/write of messages. We thought about displaying a dialog to let users confirm a hkp key, but decided on a TOFU (trust on first use) workflow for ease of use. That way average whiteout users can write encrypted emails with technical GPG users and it will just work.
Closing this issue... the feature will be in the upcoming release.