PGP has been around for almost 20 years, but email encryption is not used by most 'regular people'. At the moment, with Snowden's NSA revelations (which should not be a huge surprise to anyone), the Heartbleed bug, etc. many people are becoming more interested in encryption and privacy, but email remains one of the ways in which people send confidential information, constantly, with very minimal security. Does the current state of the art (from both a technical and social level), allow it to go mainstream?
Software companies and email providers
Default support for PGP from Microsoft (Outlook.com and the Outlook mail client), Apple (default support in iOS and OSX), Yahoo and Gmail. They should make people aware, and create pgp-wizards to set it up with a few steps.
Google can make this happen, but they have a conflict of interest, bigger than Apple or MS. Maybe they can come up with a solution that keeps their business going and our mail safe.
A possible problem: the war on terror and those "thug states". Companies from the US are not allowed to export certain technologies to those countries. But I don't think this is the real problem, as these technologies are freely available worldwide.
Facebook and Twitter are not big parties in this, but they could start awareness campaigns, as privacy is something they like to promote.
I think it should be promoted by countries. The only big enough "country" that I can see this doing in the near future is the EU, although Germany could be a good start. But that will take more time.
What we can do
Install PGP ourselves and start to use it. I use it sometimes to mail stuff to myself from or to work, if only to get used to it.
Create manuals and installation methods and show how it can be used to work without hassle. So for mom and dad it should work by default when they send an email those people that use it (which probably means those addresses should be marked as having PGP), like you and me. It should even work for them without having to enter a password. That would mean the mail can be opened by anyone on that computer. On OSX you need to login to unlock the key, and I don't know how this works on Windows, but I hope it's similar.
My amateur take on this
Technically I think in short that cryptography needs to be made easier to use. This could happen if companies like Google, Microsoft, Yahoo, Facebook, etc. implemented cryptography on their web based email. While cryptography already has been made very easy (there are for example Firefox extensions/add-ons that make it easy), it needs to be even more easy to use. Maybe a good first step would be if Google implemented a encrypt/decrypt button in Gmail. Then, later on, they could make everything run automatically. I think this process needs to be a bit of trail and error to figure out what people are actually willing and able to do. There are of course things to think about here. Will the emails now be stored on Google's servers in encrypted form? If so, how will Google be able to deliver targeted ads to you?
Socially I think you need first convince people that the need cryptography. I get the feeling that the average Joe on some level simply doesn't care about encrypting his email. He might be all frustrated about what the Government spying on him , but he also doesn't really care enough to go through the trouble of encrypting his email. And here personally I personally don't feel (yet) a real need to encrypt my standard emails. If I am writing my grandmother to tell her about the new cute cat that I just got, I don't mind if, say, the government has the capability to listen in (I am more worried about other hackers). I have nothing to hide. If you want me to encrypt my email, then you definitely have to make it easy for me. I am trying to be a bit of a devil's advocate here, but I think that many people think like this. It is just reality. You might be convinced that you need to encrypt all your email, but the average person doesn't. This is why I wanted to give my amateur view on this. So, again, maybe if you can convince the large companies to implement cryptography so that it is done automatically that would help.
You mention above the export restrictions and I don't know how big a deal that is. But maybe the companies can just have different products designed for different audiences.
After (or along side of) having created a desire for cryptography, you possibly need to teach people about cryptography.
And if you want to get the big companies involved, they would also need to restore some trust with the public. After it was made known that these companies cooperate with the government, I think many people are not willing to trust that say Google will not, say, keep a copy of your password/secret key. But maybe people also don't care about that?
If you want just email encryption it would probably be enough that the major mail providers include an S/MIME certificate with each mail address and use it by default inside their web interface and make it easy to use in standard mail clients.
But, if you want real security and not just encryption you have to start somewhere else. The major problem is not the encryption part, but the trust part, e.g. is the sender of this mail really the one (s)he claims. While you have trust models with S/MIME and PGP they are not sufficient to provide the necessary trust, because it does not assure that the current owner of the certificate or PGP-key is really the one the certificate/key claims:
- What checks did the signer of the S/MIME certificate to verify the claimed identity? How trustworthy are the peers which signed the key in the PGP web of trust? If you've got the certificate/key from the owner in person it is much better, but how often is this the case?
- How can you be sure that the certificate/key wasn't compromised and now somebody else is misusing the identity. Revocation needs that the owner is actually aware of the compromise and it also needs to be working, which is not even the case with the much simpler structure of the PKI we use for https.
I actually like the idea of ZRTP (encryption for VoIP), where you create a mutual trust by exchanging device specific keys and verifying the trust through another channel (in this case: voice). It's simple to use and works fine as long the peers already know each other enough (so one can distinguish the voice of the peer from the voice of a man-in-the-middle) and the device gets not stolen or otherwise compromised.
Maybe a similar scheme could be constructed for mail, but like ZRTP it will fail if you don't know the peer well enough. In this case you again have to use proxies which assure you the trustworthiness of the peer, e.g. back to S/MIME or PGP :(
In summary: it all boils down to trustability, which is easy if you know the peer personally and is hard if you need to trust proxies to make the right trust decisions for you. This is not a problem of mail, web or whatever because you have the same problem in real life.
Lets take a step back. If we added some form of TLS that allowed for an "On The Fly" key exchange like we have with SSL web sites, this would already be a big step forward.
Yes, PGP and related technologies that would keep your email from curious ISP's as well is an even better step forward, using an SSL/TLS style tunnel to move data between mail servers would allow for authentication of the source server (ie: You know for sure it was a Yahoo server that passed you the message).
How much SPAM does a person get a day with a spoofed source domain address? This would help prevent much of that (it would all have to be smaller domains that don't have certificates).
So, add a new hand shake to the SMTP protocol that would allow the sending server to the share their public key along with the message. Then the receiver can validate the key as being issued to the proper domain via a key authority/depository (entrust, etc).
The problem of security while in transit is atleast addressed and the email systems users need to NOTHING to make it happen.
Sure, this does not address email while at rest on the source server (so Google can still read it and present advertising), but atleast now it's just you and your ISP, and not the whole world. Plus, if you want to run PGP on top of that, you still can.
A little security is still better then none, especially if there is no price to be paid for it by those being secured.
On top of what others have suggested, there's one fundamental issue here: the human side. It's not a matter of tooling or mathematical background. We have these already. What we need is to get out of
For e-mail encryption to go mainstream, it needs to be the path of least resistance. As in - encrypt by default, transparently, unless the user explicitly decides to decrypt.
It's the same argument for HTTP vs. HTTPS. Somebody wrote (sorry, can't find the link any more!) that we should not consider HTTPS the "secure" version of HTTP. Instead, HTTP is the "insecure version" of HTTPS. It's a subtle but very important difference.
Of course this shifts the problem domain from tooling (something we're good at) to psychology and dealing with human beings (something we're not very good at, especially for a nerd). On top of that, it requires a transparent, secure, and reliable layer on top of everything. For example,
- User authentication: if there's going to be automatic encryption it will be with public key. How do you keep yours secure? In the browser scenario above, how would that work?
- Certificates, revocation lists and all that mess we haven't figured out how to handle properly yet.
- Error messages and clear fallback. If my grandma sees an OpenSSL certificate error, what do you think she's going to do? I'd rather avoid human intervention whatsoever and not assume the end user is the wise one.
Secure email LOL.
Cryptography requires keys, and essentially the average person is just too stupid to use them properly. Until we have the technology to build a pervasive system where you somehow are the key, and whatever computer you use to send "messages," email, text, voice, video, etc, can consistently recognize you as your crypto key, encryption just isn't going to work.
There are plenty of companies that will tell you they have solved this problem, but they are not telling the truth, they're attempting to sell you something. Let's take webmail for instance. Let's say you're going to use S/MIME, so you buy a personal certificate, which requires you to identify yourself in the real world someone supposedly responsible -- a bank officer for instance.
This certificate contains a public/private key pair. The public key goes onto (as implied by the name) a public server. The private part, though, has to be kept private. Read that again. Has to be kept private. So, where in your webmail system are you going to store that? In the super secret private storage at the webmail provider, where virtually anybody who works in any role whatsoever in law enforcement or the federal government can get it, without your knowledge, simply by asking for it? Or anybody who can convincingly look like a government official?
Oh, but you say, the private key is locked with a password. Yup, I bet that's an impediment to the NSA, a drug cartel, or virtually anyone else who really wants it. You may be willing to bet on it, but I'm not.
The private key has to be kept private, except during the moments your mail program is actually signing or decrypting a message. Otherwise, it should be offline, in some convenient storage that your happy user will then promptly forget, lose, throw away, crush, drop in a drink, or in the toilet, or in the parking lot, or... you get the idea. Oh, and try doing that whole private key on a thumb drive trick with webmail. Yeah, that'll work great.
So, basically, secure encrypted email works fine as is. If you're smart enough to use it, and organized enough to keep track of your secure private key. And, as it turns out, all 3 of those guys just don't care.