[dalek_cannes]

I think it's because there still isn't a good metaphor that covers up the complexity of public key encryption. Such a metaphor is a prerequisite for a UI that the average user can comprehend.

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 [e-mail]'

2. User 2 receives '[e-mail] 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.

[claudius]

> First, I think we should rename the keys to 'locking key' and 'unlocking key'.

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…

[moocowduckquack]

That would make for nice iconography - public keys being open padlocks, private keys being keys and encrypted things being closed padlocks.

[moocowduckquack]

was bored so made something - http://postimg.org/image/8sm7otl2p/full/

[dalek_cannes]

interesting! i can clearly understand what each means, but i think the average person might get confused. how about just the key and the open padlock? signed/encrypted content can have the icon on the side (kind of like the shortcut indicator in windows)?

[moocowduckquack]

I might have a bit more of a play about with it, oh and here's the svg as a gist if anyone wants it - https://gist.github.com/anonymous/7308250

[claudius]

Okay, thinking further: The (open) (pad)locks you distribute also carry a seal impression. Then:

- 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?

[cryptos]

I like this metaphor very much. It is much easier to wrap it.

[betterunix]

"I think it's because there still isn't a good metaphor that covers up the complexity of public key encryption. Such a metaphor is a prerequisite for a UI that the average user can comprehend."

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.

[LiamMcCalloway]

As everyone is pointi ng out, usability is too low. A good target for usability would be TextSecure, the OTR for sms Android app (why I'm sure everyone is using).

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.

[kintamanimatt]

The problem with the key exchange mechanism you've described is it's untrustworthy. The software would be essentially asking "is this initial email from the person you think it is?" which is a tough question to answer given the fact that emails can be readily spoofed. Granted, Bob's key will differ from Mallory's key, but there may be just enough time to do bad things before detection.

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.

[a3n]

> 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.

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).

[steveklabnik]

This is why theres the web of trust concept. Which is even harder to explain than public/private keys.

[nmcfarl]

I'm not sure the general public needs the level of trust you are describing. The have an email address somehow, from a Facebook chat, business card, or spam mail - and that's the level of trust in identity they are currently comfortable with.

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. )

[ctz]

> Key exchange between people should always require some kind of offline verification.

Or a trusted third party (see IBE.)

[kintamanimatt]

They have the same benefits and drawbacks of CAs.

[avian]

> 4. Provide a 'compose secure email' option

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.

[fragmede]

Locking/unlocking key is a great way to think of them!

The issue, in my mind, however, is less the conceptual issue, but more that there's not good way to encrypt gmail/yahoo mail.