A friend and I were discussing this over dinner and couldn't really pin point the reason. Both of us came across ideas around what could be done to make the situation better but were drawing somewhat of a blank on the question of "why is this not already done?".
First, I think we should rename the keys to 'locking key' and 'unlocking key'. I've had people still scratch their heads at 'public/private' a few days after I've completely explained the concept to them. They find it easier to understand that a lock-only key can be shared freely while an unlocking key has to be guarded.
Second, key exchange and storage has to be transparent to the user. The process can go something like:
1. User 1 clicks 'setup secure email with user2@domain.com'
2. User 2 receives 'user1@domain.com wants to setup secure email with you. y/n? (first make sure that this is really his/her email address)'
3. Based on the response, keys are automatically exchanged and stored.
4. Provide a 'compose secure email' option
5. When adding email recipients, the encryption happens automatically. Recipients with no keys are not allowed in secure mail, obviously.
6. The encrypted form is never displayed on screen. Only a lock icon.
7. On the receive end, a passphrase prompt is displayed when a secure mail is opened
Perhaps commercial/proprietary clients already do this, but none of the free ones I've tried are like this. So I'm stuck with using GPG with only with those who understand how the thing really works.
Why not go a step further and call one ‘key’ and the other ‘lock’? So you can share (copies of) your lock freely with others, and if they want to send encrypted email to you, they take your ‘lock’ and put it on that email. It then becomes obvious that you shouldn’t share the private key (after all, anybody could then unlock the locks) and that you have to make absolutely sure that you get the correct public key from others (as putting a ‘false’ lock on a letter doesn’t help).
Sure, this falls somewhat apart if you also want to consider signing…
- to encrypt, the user takes a padlock of the recipient and adds it to the message.
- to decrypt, the recipient uses his key to open the lock.
- to sign something, you use your key as a seal, creating a unique impression on the message
- to check a signature, the recipient compares the impression on the message with the impression on the lock.
Does that make at least some sense?
We already have that metaphor: the private inbox. People assume that their inbox is private and that nobody else can read it; public key encryption is how we ensure that is the case. The UI should treat a public key as a destination.
In fact, we can set things up so that an email address is a public key, though it requires a private key generating authority:
https://en.wikipedia.org/wiki/Identity_based_encryption
Before dismissing this, consider the following:
1. The key generating authority can be separate from the email service.
2. We can make threshold key generation systems, so that no single entity can decrypt anyone's messages.
3. The sender picks the authority/authorities that the receiver will use. This solves one of the biggest problems with PGP: no matter how badly you want to encrypt, you need the receivers of your message to set up their public keys first.
Essentially, TextSecure works because: 1. It reverts to completely normal behavior if the recipient doesn't use TextSecure. 2. It automatically sets up keys if it recognizes the recipient uses TextSecure. 3. It never asks you for anything besides a password when you start the app the first time.
Point 2 is the difficult one for email, as is the the fact that people use email on a variety of devices, requiring syncing between computer/devices.
I would suggest emails get a X-smtg header which advertises the sending device is PGP capable, and the email client prompts the user automatically to set up key exchange. Remains syncing, which afaik isn't the hardest part.
Key exchange between people should always require some kind of offline verification. If you don't do this, you can't really trust that the person you're communicating with is who they say they are. It's this key exchange process that's a pain in the ass and prohibits PGP's adoption. We've kinda solved this already with certificate authorities, but they're now considered a weak link in the chain.
I know a lot of people who I've never met IRL and likely never will. When you think about it, I already don't know that they are who they say they are.
Many of them live far from me. I don't see a practical way to exchange keys with them offline. You have to travel and do it face to face, or trust that USPS, UPS or FEDEX haven't been compromised. Sure, that's very unlikely for Joe Blow, but still, you're doing it offline for security.
Lastpass and probably others have an online secure exchange tool, but then you have to trust Lastpass (which I currently do, if very uneasily).
Adding a key exchange with the identity they have - the person handing out biz cards could be lieing about his identity, but if someone else spoofs his key, he will not be able to read the email which will still end up in his inbox, not the spoofers. So now the spoofer needs to control this guys whole box to read and delete the emails, or else he'll be detected. At this point if your box is compromised, pgp isn't providing security. ;)
On the whole it sounds easier to impersonate biz card guy, than to just spoof his real email address and provide a fake pgp key.
(And as for unsolicited mails identity being trusted - Nigerian spam does still work, but the message has gotten through, even to the general populace - people know there is no assurance that identities are real. We just need to NOT undermine that distrust when adding pgp. )
Or a trusted third party (see IBE.)
There should be only one "compose" button.
If you have exchanged public keys with the recipient, all content sent to her address should be transparently encrypted, period.
People don't care about special "secure" buttons that clutter their screens.
The issue, in my mind, however, is less the conceptual issue, but more that there's not good way to encrypt gmail/yahoo mail.
Email needs to be encrypted opportunistically, without user intervention. GPG could do this; it could generate semi-ephemeral keys as needed and use key continuity, like OTR, to figure out which keys were kosher for which addresses.
Instead, GPG exposes to its users the metaphor of a "key ring" with different kinds of keys and key signatures. That model works for people like me, who use it to secure corp-to-corp communications where I have very specific and fussy requirements for whose keys I'm interacting with. But it doesn't work for end-users at all.
Someone should write a secure-by-default email client that uses the OpenPGP message format and is compatible with GPG, but that ignores the intended GPG security model entirely.
1. A UX that is... Hard. As you say. See the last few minutes of this talk I did: http://youtu.be/LjZk8PP-u3c
2. You can't PGP with webmail.
3. You can't PGP on mobile.
4. This means that unless you're on your desktop, you can't do things like search through older emails, which is really important.
5. It requires both people to use PGP.
I fully agree with your final sentiment. If I could fork myself, this is one of the things I'd be putting a ton of time into.
2. http://www.mailvelope.com/ https://countermail.com/ http://www.hushmail.com/
3. http://code.google.com/p/k9mail/
4. Well, you could if you jump through some hoops. Which describes using PGP in general.
5. Not only that, it requires both people to use it _correctly_.
Someone (my company) is trying: https://parley.co
- Lacking GPG support on iOS devices, the available apps are not integrated with Mail.app (iOS).
- GPG support on OS X devices is usable with Mail.app and GPG Tools ((https://gpgtools.org/) but encrypted mails are not searchable. I use folders etc. but it is still often a pain do browse manually through mail after mail until you find the one you've been looking for …
- Webmail, for example Gmail or Outlook.com, and GPG don't fit together well – if at all.
- The public keychain is not made for use on more than one device, i.e., it's not sync-ready.
- Key verification is bothersome, i.e., you have to attend key signing parties etc.
- There are political issues, e.g., should you upload your keys to key server? If so, with or without signatures? If you upload signatures, you create not only a web of trust but you also expose at least parts of your address book.
- Key servers store long invalid keys and there is no way to remove such keys. The PGP.com key server removes keys if you don't confirm them by mail from time to time. On the other hand, the PGP.com key server only accepts one key per mail address.
- Etc.
I'm not sure if mail encryption in the browser is a good idea, especially with regard to the protection of private keys …
And I'm wondering why Mailvelope doesn't support mail signing?
> Mailvelope currently does not support signing of messages.
Even people who have taken the time to install and use PGP, and who seem to want privacy, make weird mistakes such as "Messages encrypted to public keys, to passwords and passphrases, and PGP messages not encrypted at all!"
http://ritter.vg/blog-deanonymizing_amm.html
Usability of Security: A Case Study of PGP 5.0 User Interface http://reports-archive.adm.cs.cmu.edu/anon/1998/abstracts/98...
"Why Johnny Can't Encrypt" http://www.cs.berkeley.edu/~tygar/papers/Why_Johnny_Cant_Enc...
“I hardly ever run PGP. When people send me PGP encrypted mail I have to go through a lot of trouble to decrypt it. If it’s coming from a stranger, I’ll say please re-send this in plain text, which probably raises their eyebrows.“
http://www.forbes.com/sites/parmyolson/2013/08/09/e-mails-bi...
Moreover, it's certainly not in SV's vested interests (regardless of recent protestations to the contrary by google, facebook, etc) to see secure mail become the standard, and by extension to broadly educate and move the consuming public to a mindset of security first.
All of that said, the average end-user is/would be befuddled figuring out the use of shared pub keys, the web of trust concept, and in moreover, PKI in the bigger picture.
And even if you could get broad use of pgp going for message payload privacy/security, you don't solve the problem of metadata if you are using the current email protocol.
It's long past time for a new persistent messaging protocol that addresses metadata leakage and payload security comprehensively. There are people working on this now. Hopefully that will drive some positive steps forward on this issue.
I have yet to see any other reason for why PGP is not even used by people for whom it would be easy. Even within the security and cryptography research communities it is rarely used.
The solution to this particular problem is to have smartcards; while we are at it, we should also use smartcards for authentication, so that when you sit down at your friend's computer you plug in a smartcard to log in and to read your messages. Unfortunately that means we need to deploy a bunch of new infrastructure, and I would not count on any help from governments or from the tech community (which is largely monetized by violating user privacy).
I can imagine this could easily get rolled out if you integrated the public/private keys into driver's licenses. A quick search online suggests that blank cards are about $.06 each in bulk [1], but smart card vary between $.60 and $1.50 [2] (don't take this as definitive - I have no experience purchasing them). I don't think anyone would care paying an extra, say $2 or so whenever they get a new license for the cost of the card plus recouping the cost of hardware to print them.
Phase it in over time - have hand-outs at the DMV answering "What's this funny chip on my driver's license?" Gradually phase it in over time for online tax payments/water bills/etc. - something like "your username and password will be good until {date reasonably far in the future}, but after that you'll need a card reader. You can purchase one for $15 from any of these retailers: ..."
Once both the cards and readers are in place, it's a lot easier to get the critical mass to push for stronger authentication from banks, online retailers, etc. People worried about privacy implication could purchase their own cards from independent retailers and put their own keys on them.
[1] http://www.smartcardsupply.com/Content/Cards/cards.htm
[2] http://www.smartcardsupply.com/Content/Cards/ISO7816.htm
Interesting. Do all of their work computers run Windows?
The solution is to make software so the smartphone can act as the smartcard if you really want to go that route.
Smartcard readers exist, and certain institutions use them already, the problem is getting the cards and readers to the masses.
I guess it's one of the virtues of having a population a tad smaller than 1.5 million.
So, to me, the obvious answer is that if you want to use PGP, you first have to make everyone you intend to communicate with also use PGP. That's an obvious no-go. I would be happy to set it up, but what good would that do me?
PGP is enabled by the recipient, not the sender.
If I release my public key (convincingly authenticated), it's up to the sender to take their time to use it.
And that is probably even harder then getting people to quit facebook...
There should be a popular messenger that uses xmpp with otr by default.
Then the fun really starts. You send your message, other party claims it could not be opened. So you go through the hoops again and re-send. At this stage you have probably changed a word or two in your source document. But that does not bother you because you are new to this. You send again. Another reply comes back - 'sorry mate...' - so you send again, probably introducing a few more edits.
Then you never hear back from them ever again. As it turns out you have been man-in-the-middled and those requests for a re-send were purely in the expectation that you would change your message slightly. This provides the 'crib' needed to open your message without knowing the key by our friends in Gloucestershire.
Where did my tin foil go?
Simple and secure mail is an unsolved problem.
Setting aside the social problems of explaining cryptography and generating a network effect, most people assume their communications are not worth listening to. "If they want to listen to/read my mom drone on, they're welcome to it!" Or they assume it happens to "someone else."
I'd expect that most people -- rationally and correctly, I might add -- conclude that it's unlikely to happen to them in any way relevant to their experience.
Anything you suggest has to overcome that inertia. Facebook was a value-add. Cryptography's value-add is subjectively nil and possibly negative (whoops laptop stolen lost my keys) if you don't see the benefit in the first place.
I think the logistical and conceptual parts of key exchange and verification are probably the most difficult for new PGP users. There are some ideas to make this more convenient; I know people who've produced some nice educational materials, and a colleague has a nice idea for making key exchange faster and easier among people on a LAN.
But I think the biggest obstacle in the long run may be just how fond many Internet users have become so fond of webmail and of being able to read their e-mail from any device. Having to use one particular desktop e-mail client on one particular machine to read encrypted e-mail is normal to me but may seem like a huge sacrifice if that's not what you're used to.
It needs to be a fundamental part of the individual apps' (email, web, etc) specs, or more ideally part of the underlying internet (tcp?) that apps are built on.
There's an old joke about Unix to the effect of "it's not user unfriendly; it's actively user hostile". Likewise, many aspects of PGP, E.G. key generation and management, web of trust, public key validation and keeping the private key secure that is utterly befuddling for the vast majority of people. This, despite the fact that it's one of the most accessible avenues for secure communication we have right now.
If people have things that are easier to use securely, more people will be secure.
I've also always found them to be very difficult to configure. I use one SMTP server on campus, and need to use my ISP's SMTP server elsewhere? What if I'm on public wifi? And how do I authenticate on that server when my credentials are from someone else? How do I get Gmail to play nicely with my folders?
PGP, in contrast, was not hard to set up.
1. Portability. How do I manage keys across my computers, phones & tablets?
2. Ease of use. What do I do to set this up? Most common clients don't support PGP out of the box. Even once plugins are added, they are complicated to use.
As a result, no one uses it. So, if you want to start, you need to convince your friends/colleagues to also use it.
I've recently started signing email from my home computer as a hint to others to do the same. So far no takers.
When you hit send, a shared key should be negotiated with the recipient before your text leaves your box, without you really knowing it.
The key could silently be negotiated on top of the same protocol through automatically generated emails containing key setup information in headers (but empty "body" fields).
Specs for those key negotiation headers could easily go in an RFC, and systems that don't speak the language could then be shamed as noncompliant.
Heck, even your desktop can be completely compromised. I think there's a big chance it is. If not by the NSA then by some malware.
https://www4.symantec.com/Vrt/offer?a_id=109355
No need to pay - you just need to go through the rigmarole of getting a trial registration.
https://en.wikipedia.org/wiki/Default_effect_%28psychology%2...
b) google would LOVE it. no more context sensitive ads. let's shut down free gmail then.
c) a and b intersect - if you're using gmail or ANY other big webmail provider, you just. don't. care.
2. Encryption is extra risk for your data. If you lose the keys, you lose the data. People are bad at backing up their data, why they would be better at managing their keys? Being sloppy with your keys means that somebody can impersonate you with more credibility (what if banks would accepting PGP singed orders in email)
3. Value from widely used PGP happens mostly in society level. Encrypting any particular piece of data has negative expected value in most cases.
4. Using PGP requires understanding the basic concepts and using it well is not that easy (lots of pest practices). People don't know any of this stuff. Even public and private key is far out concept for most people.