What will it take to get people using PGP for email?

Here are some problems, from the top of my head, in no particular order:

  - Subjects can't be encrypted.
  - Encrypted mailing lists are complicated. Do you reencrypt in the middle?
    What software do you use? The mailing list manager you use right now probably doesn't support it.
  - Enigmail still doesn't support storing e-mails decrypted*. As a consequence, full-text search doesn't work.
  - There's also S/MIME.
  - Theres no software to manage public/private keys enterprise-wide.
  - Legitimate server-side email retention requirements for enterprises
  - Many people are quite alright with "most other people won't be able my email; maybe governments can".
  - Most emails quite simply aren't that important.
  - How do you deal with lost keys?
  - Webmailers
  - Often, as a sender at a company, you can not afford to inconvenience contacts.
  - No easy way to synchronize keyrings.
  - Server side spam filtering not possible
  - Out-of-office auto-forwarding
  - The other side uses gmail.
  - Your mother keeps asking why you aren't on Whatsapp.
  - The "metadata" (who mail whom? when? how long are the emails?) is quite telling.

Please solve all of these.

Sorry for the unreadable list. Thank pg for the shitty markup format.

My highly cynical take: education. It will fucking take education.

All this "oh my god but PGP is so complicated, how can a regular user be expected to use all this?" thing is crap we use to delude ourselves into ignoring the fact that most e-mail users are too ignorant to understand why invasions of their privacy are so dangerous, let alone that it can be done or how.

Seriously, it's not complicated. There are a ton of everyday tasks that are far more complicated than setting up and using Enigmail, and yet average users do them every day. If people can set up a fucking network printer with HP's crapware, they can most certainly use a PGP plug-in for their e-mail client of choice.

PGP does have a lot of problems, from unencrypted subjects to usability problems with mailing lists and stuff. But it's still better than nothing, and if poor usability were such an important factor, Altair 8800 would have been the first and last PC.

But even if all these problems were to be solved, we'd still face the fact that the vast majority of e-mail users don't even know what a mail client is, don't understand just how widely-available the contents of their messages are, and don't really understand the far-reaching implications of them being available pretty much in the open.

And even after that, we'd have to face the even sadder reality that this is but a really tiny win in terms of privacy, because convincing people to use PGP is nothing compared to convincing people to stop using Facebook, Google and webmasters to stop using the tracking shit that fills 90% of the post-web 2.0 pages.

Difficulty is problem #0.

PGP is fucking complicated, annoying, and non-user-friendly to use as a computer literate individual that codes for a living. How do you expect the chain-email-forwarding-toolbar-installing-click-here-for-free-smileys average person to understand it, with the knowledge that screwups in encryption land have the very real possibility to render all that work useless?

The average person doesn't see the value proposition for going through all that effort. Shouting "GOVERNMENT SCARY" at them isn't going to work.

Solving problem 0 would be a massive net benefit for society. You need a cross platform and cross client tool that looks good, is easy enough for my gran to understand, and that does the encryption right.

There is no such tool that exists today.

The Catch-22 is problem #1, after problem #0.

You can encrypt your own stuff all day long, but you aren't emailing encrypted stuff to anyone until a critical mass of people have also gotten past problem #0 long enough to have avoided saying "fuck it" and have distributed their public keys to everyone they know.

On top of all this, you're pushing encryption as a philosophical measure rather than a practical one. For more on how pure philosophy holds up when practicality intrudes, look at the free software movement.

> PGP is fucking complicated, annoying, and non-user-friendly to use as a computer literate individual that codes for a living.

I really don't think it is. Yes, it took me two days or so of reading stuff and chaining commands when I was using mutt. Enigmail is literally point and click. You follow a wizard with three screens or so to set up and all you need to learn after that is how to do the whole web of trust thing. It takes about as much time as it takes to learn Word's stupid track changes mode.

Don't get me wrong, I'd love to see it even easier to use, but it's in a state where it's pretty much useable without being a hacker.

> Shouting "GOVERNMENT SCARY" at them isn't going to work.

Not only government scary. People don't understand that snooping e-mail isn't done only by the government, it's also done e.g. by, and for the benefit of, media agencies. The combination of Gmail and Google's bubble alone is enough to limit everyday choices for them, like purchasing things, learning about controversial matters and planning a holiday. Even in the post-Snowden world, most people don't understand that there is a huge audience for personal data besides the NSA, and it has an impact on everyday life beyond scary slogans like surveillance state.

> On top of all this, you're pushing encryption as a philosophical measure rather than a practical one.

The same can be said of many things that otherwise look idealistic. People are also pushing for widely-available education, or research in fundamental topics like particle phsyics, for what look like "philosophical" reasons rather than practical ones. The gap between "philosophical" and "practical" seems to be one of volume: it's "philosophical" when few enough people understand why it's practically necessary. It's a trait of perception, not an inherent trait of the object, which is why I think it's a matter of education. 30 years ago there seemed to be very little practical value in PCs, too, and anyone pushing for widely available computer use was, at the time, as much philosophical as I am about this today :-).

Edit: not that I am denying the gap that exists between implementing purely philosophical principles and implementing purely philosophical principles in a practical way. Linux is, in many ways, less "free" in terms of philosophy than GNU Hurd is. I'll gladly buy a gallon of beer for anyone reading and replying to this post from a computer that runs GNU Hurd.

As someone who's spent a lot of time and money trying to solve this problem, I will say that the biggest impediment is usability, and the largest technical hurdle on that front is key management (general users will never, ever take the time to understand what they're supposed to do with their keys). Beyond those problems, though, are the other problems mentioned elsewhere on this page; the inherent weaknesses in email that PGP can't circumvent (specifically the meta-data leaks--who is sending messages to whom). I think Adam Langley's Pond[0] is the most interesting candidate for an email replacement, although it's not yet ready for prime-time (and even further from a level of usability that could reach mass appeal).

[0] https://pond.imperialviolet.org

The only way to get people to encrypt their email will be to make them want to encrypt their email enough to overcome whatever hassle it takes to do so.

Most people seem focused on making the second part of that equation (the hassle) small. Which is great. But even if you can somehow get it to 0, that may not be enough to get it over the hill.

That leaves making people want to encrypt their email. And abstract notions like the NSA aren't going to be enough. It needs to be personal and immediate. So: if you really want to encourage secure email, start intercepting clear email and responding to it. The surprise introduction of a third party in the email conversation will cause most people to realize their email is not secure (which almost everyone doesn't know) and create an impetus for action.

Now, this is a pretty nefarious scheme (grey-hat at best) and extremely dangerous due to the inevitable legal freak-out, and I'm not going to be doing it, but if I wanted to encourage the world to move to secure email, it's how I'd do it.

I think the sad truth is that not only is encryption inconvenient for most emails from most users. It is just not even necessary. So, you are trying to decrease convenience for...?

It is worse in the web world. I want someone to be able to index my emails. As I do actually search on them rather often.

Unless there is a homomorphic technology I'm not aware of (very possible) to allow searching over encrypted emails, then I don't know how you can get around the fact that there is a third party that has access to the unencrypted. Once that happens, game is over. Right?

well, you could keep a copy/index locally and just search through that..

Right, a fairly massive decrease in convenience. And renders search for email rather worthless on my phone. (Which, to be fair, is already rather crappy.)

Make email work exactly as it does now, but it is encrypted -- then people will use it. If you make it more inconvenient then it is a non-starter as email privacy from Google or the NSA just isn't a concern for 99.9% of people (stat made up).

Google is a great example. People were warned about severe privacy risk of using GMail, but Google made it really easy to use, has amazing spam filtering, and gave away 1 GB of storage.

Google Now is a similar one I think. I'd rather Google surface purchases, flights etc. in Google Now than not, even if that means they're reading them emails and know what I bought.

I read an article the other day about how jihadist software developers were complaining that higher-up leaders in their terrorist organization refused to switch away from GMail. And this from the very groups that should have known better!

I can only assume that problem has been fixed after Snowden leaked PRISM, but it illustrates the mentality you speak of quite vividly.

It seems to me that S/MIME has a better chance for wide adoption due to it being built in to many email clients (Mail on OS X/iOS at least.) However it's still up to the user to get a certificate, which is a barrier. But I'm curious what others think, as I haven't seen S/MIME brought up in the recent encrypted email threads.

It's true, S/MIME would seem to be a more convenient method for wide adoption...

The problem with S/MIME is that it is strictly hierarchical. That already hasn't worked well for TLS.

The aim of email encryption is in a large part to prevent government-level parties from reading the emails. It doesn't really make sense to then go back to a system controlled by the very same parties.

OpenPGPs web-of-trust model seems more appropriate.

But both approaches share a significant number of problems, so...

Yeah. They're pretty much free too, from Comodo and Startcom. You can get one for ~$10 from Certum (what I use) and $30 from Globalsign.

It's handy too, as I can sign emails using my iPhone just by importing my p12.

I think it's a great question.

When I think about why I don't use pgp personally, and why I don't encourage others to use it (besides the fact that no else uses it) it's a functionality issue. I need to be able to access my email via my computer, phone, AND web browser (potentially not on a computer I own/control). My understanding is that is not easy to accomplish - maybe I've been misinformed. Until then, it's hard to start using pgp.

To answer your question, a good place to start might be a company like Good Technology - given their involvement in email solutions for so many large corporate customers.

Here's a scheme I've been thinking about. It's an opportunistic PGP setup:

1) Whenever you want to send an email you look up the PGP certificate for the domain (yes domain) you are sending it to in some central keyserver. If you find it pin that certificate for future use and sign and encrypt the email. If you don't find it just send a normal email, possibly still signing it.

2) For a sysadmin to start using the scheme just publish a public PGP key in the central keyserver and when you receive an email that's encrypted with your domain key decrypt it and deliver it to your user.

This buys you a few things. For large hosting providers (say Gmail) you get a little better security than the current SSL between mailservers setup because it's harder to MitM and can be relayed between mailservers without security issues. You also get a PGP signature attesting that the email does indeed come from @gmail.com and isn't spoofed. Individual users that care can then use this scheme to get user-level encryption by having email in their own domain @myname.net. You could even outsource the @myname.net mail server to a normal POP/IMAP provider and publish the PGP key to the central server yourself. The provider then gets the encrypted mail and you decrypt it locally in your mail software.

But maybe relaying doesn't really happen these days and fixing STARTTLS would give you most of this with SSL certificates instead.

Buy maybe... fixing STARTTLS would give you most of this with SSL certificates instead.

Bingo.

The only thing TLS in the mail server can't give you is a way to outsource the running of your domain's MX server without trusting that server with your SSL key. If the sending server PGP encrypts instead you can decrypt it later.

That would make running your own mail a little easier. Use any normal SMTP/POP/IMAP email service to handle the network side and then encrypt/decrypt locally. You only have to trust your own mail user agent running on your own hardware. As it stands right now to run my own email (something I've been contemplating) I have to either put my SSL key in a machine I don't control (e.g. Linode VPS) or try to run a mail server on a residential internet connection. Neither seems a good option.

I thinnk PGP can't have a widespread adoption on its own. We need to piggy-back it on another network of trust.

Here's a scheme for such an application:

- By default, if the person you're communicating with is not in the network, you're out of luck. Maybe send a message along these lines: "I'd like to communicate with you but you don't have a secretcommunication key. Could you please create one so we can have some privacy ?"

- On first launch, you create a PGP pair and send the public key to networks you trust: Facebook, G+, HN, reddit, whatever. By "trust" I mean "you trust the network to give you the correct identity of your contacts": you've befriended that Maria on Facebook, so you can trust it to give you the correct public key that Maria created on her machine

- When you want to send an email to maria, your application fetches the public key on either network (if it doesn't have it already) and uses it to encrypt your communication. Note that the application MUST NOT sign the identity for you; it should just raise no warning. It MUST always be up to the user to sign these.

In a very broad sense, that's what keybase.io is doing: instead of being yet another provider of trust, it re-uses the trust you have already built in other networks.

The number 1 problem to tackle is make sure anyone who wants to create an account will also create a PGP key.

> Gmail seems like an obvious entry point ... but it would go against their business model (they could no longer mine your emails).

A few ideas why google won't mind encryption that much:

http://www.reddit.com/r/tech/comments/278cze/google_launches...

> Is there any hope?

TextSecure is already offering a secure communication service(that in my view could be a decent replacement for email). They will also release a browser extension in the future. Those(and the fact google's involved) are good signs for google's encryption project , at least technically.

And assuming the technical infrastructure for easy encryption does exist, i can see some sort of hybrid model[1] becoming popular and/or mandated in some groups, and growing from there.

[1]For example, textSecure/redPhone's model lets you send sms to everybody, but if it detects the other side has encryption , it encrypts it. There's also an easy to use method for out-of-band key verification.

When people/media/govt/everyone is/are still arguing whether the surveillance state is merited or not, whether Snowden is a traitor or not, a technical solution is meaningless. The argument over whether it needs a solution needs to be "solved" or at least agreed on enough that their is an "issue" to be "solved" anyway.

In a large company, such a change only has a chance if it is mandated from the top and then the mgmt team is very committed to push the change through for as long as it takes. Without both pieces it will get killed by apathy at the middle management layer and below. Without that support the technical solutions will gain no foothold.

First, somehow make popular email software developers (Thunderbird, Mail.app, etc.) to include OpenPGP support out-of-the box and make it easy to use. I.e. not a scary-looking interface hidden beneath 4+ clicks deep in settings, but a simple-to-get "security" button and an unobtrusive suggestion to generate or import a keypair on account creation. This is an absolute necessity. For webmail providers ask them to at least provide signature verifications for PGP-signed mail - that should be acceptable even for Gmail-like ad-based mail-sniffing business model.

Then, just start using OpenPGP. For every recepient with a known key encrypt the message, for others - sign it. Users will notice your emails have some fancy security-related icons and curiosity will eventually prevail.

Almost works with S/MIME for me (but since obtaining a certificate is not trivial - only "almost", not really).

"Users will notice your emails have some fancy security-related icons and curiosity will eventually prevail."

I wish this were true

There's a precedence: browsers and their green URL bar blocks for secured connections.

I'm going to suggest a compromise way to get wide scale email encryption rolling out: The key benefits are that (1) the user doesn't have to do anything at all and (2) it prevents mass surveillance and recording of email, but with a downside that it's not authenticated. There's significant benefit even when it's non-authenticated.

These days I get email from the other side of the Earth in several seconds. So adding a few more seconds to delivery shouldn't be a deal breaker on what I'm about to suggest.

Let every email client do opportunistic non-authenticated encryption with every other email client. That way, the user doesn't have to do a damn thing.

Example: Alice wants to send an email to Bob. Before sending the real email, Alice's email program sends an ephemeral public-key to Bob's email program -- hoping that Bob's email will promptly reply with its own ephemeral public-key. If Alice gets a reply within, say, 20 seconds, great. They can now send encrypted but non-authenticated email to each other. If Alice receives no reply or an error message, then her email program sends the email the usual way (as plaintext).

At this point, most readers will yell "man-in-the-middle attack." Bear in mind that this can be built upon and improved. The advantage is that it requires nothing at all from the user; the user might not even realize the email is being encrypted and decrypted. It requires only that the email client developers agree on the handshake mechanism.

But importantly, this thwarts the problem that we're most worried about, which is mass NSA surveillance. Yes, the NSA or others can still do targeted MITM attacks, but they are unlikely to do a MITM on every email exchange. And if they did, it would be detected and provable, and result in a backlash demand for authenticated encryption. Furthermore, clandestine wholesale recording of your emails is useless because the keys are ephemeral.

Using Gmail (or any SSL-enabled mail server) already affords you those protections. (I'm not trying to be a naysayer, just that the protections PGP provides specifically go a step beyond what you're describing, which we essentially already have.)

> Using Gmail (or any SSL-enabled mail server) already affords you those protections.

It absolutely does not.

What I'm suggesting is end-to-end. With Gmail or with SSL-enabled connections, the host (Google in your example) can read your email; the encryption there is only between you and Google.

I'm saying that the key exchange should be from your email client (Thunderbird, Outlook, a browser) to the other person's client. I think it could be made to work even with Gmail if the functionality was built into the browser.

I didn't read your parent comment as a suggestion for peer to peer ephemeral exchange. In that case you would be correct, but negotiating server less peer to peer key exchange (especially on mobile devices) isn't currently practical.

EDIT: s/parent comment/your parent comment

You could adopt a company policy that mandates PGP for everyone as it's not that difficult to create, distribute and revoke public keys for your employees. Problems arise when you try to apply this process to the larger public, as that means having people self-sign their certificates for their public keys or having one user vouch for another. But that's where security breaks. Even with CAs on the internet you're never 100% sure you're talking to a legit entity; any scenario where CA aren't even present is just a nightmare that doesn't improve security by one bit. It's not just about making sure nobody except the recipient can read emails it's also about making sure that the recipient is legit, and that's the problem.

Suppose, hypothetically, that there was some kind of ultra-phishing virus that resulted in a 1/100 chance of losing money as a result of sending unencrypted email ... people still wouldn't use PGP. They'd switch to facebook messenging or SMS or something.

It's just too much hassle. People don't use it unless they absolutely need to. Signing is slightly more common, and might be easier to bootstrap.

Start by signing your mail. We might be able to persuade banks and other phishable businesses (e.g. Paypal) to start signing mail too. That gets the keys in place.

You mention gamification; some sort of automated system that hands out rewards or does something useful if you send it a PGP-signed mail might be a way to do this.

The problem will all come down to UX.

* Key generation and exchange is a challenge. Most people I have taught how to use gpg / pgp can't seem to figure out how to publish there keys, send or receive keys.

* Entering your password often is a pain. Most people I have taught have given up using this on a day-to-day basis because its just such a pain.

As an aside, there's the problem of improper use. Right now there are too many choice as to how you can setup pgp leading to the problem of people using it wrong. And don't get me started on private key security. Most people do NOT want to think about this. Quite honestly, I agree. Something needs to be done to make it very hard to compromise your own private key.

Addresimg the issue of key availability could be perhaps achieved by OS compatibility. Eg. If two Mac users send each other an email to iCloud addresses it can be encrypted by default and have iCloud manage the key exchange. This is just a thought on using the cloud as a part the key management similar to what Exchange does. It does not mean that is not hackable since compromising iCloud would compromise both clients but it could be a good start. Encryption by default among same cloud users.

I agree with the points people here have brought up. For my part, I think it would be good to at least have a seamless OpenPGP interface with at least signing enabled for all mails (if encryption not always possible), and I'm working on https://autonomail.com to that end. Other folks (like https://whiteout.io) are also working on similar solutions.

You already identified the "usability" issues. It would need to be a system that required people to just get once a "code" for their computer. And then another systems auto detect if the recipients has also a "coded" machine.

Encryption is just inconvenient for the average user and doesn't provide some immediate benefit ("My bank needs encryption but I don't need to encrypt my funny cat pictures").

You can make a seamless experience so that people don't even realize that their email is encrypted, but then the problem becomes: if their computer crashes and they lose their private key, they have now lost access to every previous email ever written. That's just unacceptable. I closely guard several backups of my private key, but most people aren't going to create an enormous single point of failure like that.

Backups can be seamless, too.

Just a tiny unobtrusive icon "hey, your key wasn't backed up, want to fix that?" would probably do the trick.

And with a proper passphrase I think one can even backup to the cloud(tm) without much worries.

About usability. Well, I'm not an expert but runbox.com (with their roundcube interface) or unseen.is let you use gpg keys in a really easy way. They generate (or you can import) a pair of keys in the browser so they never have access to them. The only catch is that if you erase your cache or their cookies, you lost your keys and have to import them again. By default, runbox sends your public key as an attachment.

While I understand Sae5waip's list of put-me-downs, I can't really sympathise with it. A lot of the usability problems boil down to two things, namely

  * UI/UX, along with proper client integration
  * Discoverability and bootstrapping of the web of trust

Make it easy to discover users' PGP/GPG keys, and trivially easy to use them. Integrate GPG-agent or something with similar functionality so users do not have to type their passphrases all the time.

Then start with sign-by-default policy for all outgoing mail, and add a simple way to show the distinction in the mail client UI. Remember when browsers started to show the green locks in URL bars? It wasn't a panachea, but it at least made things less awful.

Now... I'm not saying it would be easy, and I certainly don't have enough hubris to claim that I could be able to design a solid, end-user friendly PGP system by myself. But I sure as hell would love to be involved in building one.

I try to imaging what the world would be if Google provided a globally reachable and easily integrated (on client side) PGP key server pool.

EDIT: bulletpoint appearance

PGP cannot encrypt the “subject” header or metadata like the “timestamp”, “to” and “from” fields.

https://www.gnu.org/philosophy/no-word-attachments.html

As an interim solution you can setup a secure contact form on your company website like https://encrypt.herokuapp.com/ - it encrypts the message before sending it to you.

From the perspective of this sysadmin: get Microsoft to build PGP into Exchange, and integrate the functionality into Outlook. It would be the tipping point you seek, perhaps the only one that exists.

We have had a similar discussion in the past: https://news.ycombinator.com/item?id=6663098

IMO, the issue is that real security is inconvenient, and my email is just not that secret.

Absolutely streamlined interface where they have to do pretty much nothing for it to work.

What it would take is to not have to know that you're doing it.