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?

  • 1
    On my side, I've seen recently several new companies/startups offering secure/encrypted email and file-sharing services.
    – ack__
    Apr 18, 2014 at 12:11
  • We are long overdue for a secure and non-repudiable mail system. (The latter would severely cut down on spam.) The biggest problem would be getting a standard adopted and support written into clients (preferably in parallel with SMTP, for now). Remember S in SMTP stands for Simple; it wasn't intended to be a final solution.
    – keshlam
    Apr 18, 2014 at 17:28
  • Currently, if the encryption is not client-side, then it's basically placebo. But the only user-friendly client-side encryption is Thunderbird with Enigmail. Many people wouldn't like having to leave Gmail and start using a program for emails. However, this cannot be the only reason, because back when Outlook and Thunderbird were much more popular, encryption still didn't go mainstream (perhaps because there weren't good extensions around).
    – Superbest
    Apr 18, 2014 at 21:05
  • 1
    Also, note how Gmail leverages Google's superb search software and spam detection, but if you encrypt you Gmail mail client-side, you lose that (and must be content with your mail client's capabilities).
    – Superbest
    Apr 18, 2014 at 21:06
  • 1
    Well, you shouldn't lose spam filtering if we assume that encrypting an e-mail for every recipient on a spammer's list would be cost-prohibitive computationally speaking. If the public key is known to the sender and the e-mail is signed and encrypted, it's probably not spam. I use Thunderbird with my own personal certificate from COMODO. It's relatively easy to use: import the certificate and set the application to automatically sign all outgoing messages.
    – Kevin Li
    Apr 18, 2014 at 22:48

6 Answers 6


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.

  • 1
    Google's conflict of interest is a big issue here. Also is exporting - but companies are already doing the export controls, at least for non-cloud software and hardware. Since Apple, for example, includes SSL capabilities in OS X, they cannot export it without US government approval. If Google adds encryption capabilities to Gmail, they cannot offer Gmail (or these features) to users in certain foreign non-US countries and territories but I'm sure they would be able to determine country of origin.
    – Jason
    Apr 18, 2014 at 12:12
  • @Jason - Well, only if they ask for something that ties it to a real-world identity (that states where they are), otherwise people can use things like Tor, or just a vanilla VPN connection... On the internet, it's trivial to lie. Apr 18, 2014 at 13:20
  • 2
    Could you elaborate on what exactly Google's conflict of interest is?
    – Ajedi32
    Apr 18, 2014 at 16:13
  • 3
    @Doval: But neither transport-layer security nor application encryption for mail exchange prevents the recipient from accessing the plain text. With gmail, mail.google.com is the recipient of the (encrypted) message, and the origin of the encrypted web page. Only end-to-end encryption that relies on a decryption key on the user's device would conflict with google ad-matching, and then you lose the convenience of using any web browser to access your mailbox (securely, except for Heartbleed and similar bugs in HTTPS)
    – Ben Voigt
    Apr 18, 2014 at 17:41
  • 1
    The German BSI "promotes" and explains the use of OpenPGP (1, 2). They even commissioned/supported the development of Gpg4win.
    – unor
    Apr 18, 2014 at 18:57

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.

  • 1
    Did you have a look at DKIM? I think this does already what you are proposing, e.g. making sure that the senders domain actually matches the mail server in came from. And its already in use. Apr 18, 2014 at 14:44
  • "How much SPAM does a person get a day with a spoofed source domain address?" Nearly None. < 1 a week that I actually see.
    – jjanes
    Apr 18, 2014 at 22:05

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,

  • Web mail: JavaScript code that encrypts client-side and does all the key validation transparently.
  • 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.

  • You're taking this way too far and complaining about security in general. The only fair point I see is that people are not used to working with public/private keys directly.
    – Navin
    Apr 19, 2014 at 1:04
  • I think you've got it wrong. When you send mail, you encrypt the contents with the recipients' public keys. When you sign the contents, you do that with the private key. On the other end (the recipients' ends), the content is decrypted with their private keys and the signature is verified using your public key (which they have). The public key can enver be used to decrypt your mail barring future cryptographic advances.
    – Kevin Li
    Apr 19, 2014 at 4:47

Not the answer you're looking for? Browse other questions tagged .