Wake me up when they finally offer a scalable key management system. PGP always punted on key management, and as a result has been a perpetual market flop. It always seemed to cater to people who were very willing to give up all convenience for perfect security, like can't trust keys unless they were handwritten on paper and you verified their photo ID in person before accepting them levels of paranoid. It's really frustrating for people who want a system that's good enough to always be there and providing passive benefits even if there is a theoretical case where a nation state might MITM your communications if they got there before you knew the person.
And yet, without it, the Snowden leaks wouldn’t have happened. I mostly agree with you, but it’s worth pointing out that they achieved their goals; rare for a security product.
Yeah, I dislike the idea of prioritizing a crypto standard that doesn't work against nation-states. Some of us like our privacy.
That said, I agree with jandrese's point about key management -- low-security key management solutions shouldn't prevent people from taking a high-security approach. Seems like the ideal situation would be if the really paranoid people end up naturally testing the low-security infrastructure as a side effect of doing their paranoia stuff. E.g. if the gpg client was set up to automatically report discrepancies between a user's personal web of trust and a presumed-authoritative keyserver.
That said, it's unclear to me why Signal wouldn't have worked for Snowden -- interested to explore details here.
> Wake me up when they finally offer a scalable key management system. PGP always punted on key management, and as a result has been a perpetual market flop.
What is the alternative KM architecture in a distributed system? Remember that for e-mail there is no central authority to handle assigning keys to individuals, unless perhaps you want Gmail and Outlook.com to handle that.
The other e-mail security system is S/MIME (which uses X.509).
It's not hard to imagine a system where you can contact the server in the MX record for a domain over HTTPS (really just TLS) and query it for a specific email address to get the public key for that user.
Sure if someone knocks over TLS then your email encryption will be in trouble, but you will also have plenty of other problems at that point.
In a draft published in May of this year. This should have been a draft in the 90s.
It should have been in mail systems forever. Whenever you create an account the first email should have been the server sending you your private key in some format that every email client understands and would then prompt you to automatically install it in your client for that server.
Welcome to your new email account!
Your private key is attached in the standard format.
When your client asks you to install the key say "Yes", and allow it to automatically sign your email using that key for this account.
Don't forget to check the box to automatically encrypt mail when possible.
If email worked like this I bet secure POP and IMAP would have been implemented much faster than they were in real life.
Why not use the SRV record which has been created for this purpose, advertising seervices, specifically and use port 11371/tcp which has been registered with IANA for OpenPGP HTTP Keyserver? Why create new non standard mechanisms when these already exist? One could even use a different port and protocol with SRV records.
What if your mail server decides to advertise their public key instead of your public key, allowing them to read all of your email with you being none the wiser?
One way to solve this problem is Key Transparency, which aims to provides a mechanism to verify that you're receiving a legitimate key, somewhat analogous to Certificate Transparency.
We've implemented this at Proton: https://proton.me/support/key-transparency (although it's still in beta, and opt-in for now - but obviously the aim is to enable it by default).
Really paranoid folks could set up services online that check for this, but I kind of doubt it would happen very often because it would be a major stink for that email service if they were caught, and catching them isn't that hard.
The problem with existing keyservers is that there are several of them and you never know which one someone's public key might be living in. There may even be multiple potential keys for a single email address across the different servers. They are effectively useless for email encryption in their current form. It's a very rare email client that will even query the most popular ones looking for someone's key. In fact I don't know of a single email client that does.
