Singpolyma

Technical Blog

PGP UI Suggestions

Posted on

Lets face it: currently, PGP is hard.  Most geeks even consider it “geeks only”.  While few average users can benefit from encryption (few people say things that secret) – everyone can benefit from signed authenticity (at very least to cut down on spoofing).  The biggest obstacles to end users are (a) they don’t see the point (b) they freak out when they see “weird” inline content or attachments (c) verifying long hexadecimal signatures is hard.  I will make suggestions about these is order.

The fact that users don’t see the point really is the biggest problem.  If more users cared about authenticity, more would be willing to endure the pain of doing things “right”.  My hope here is that if seamless enough solutions become common enough, some people will use it because it is “right there” and as more people they know are sending signed messages perhaps some network effect can be leveraged.

Weird content is on it’s way to being fixed.  If everyone installs FireGPG and uses a mail client (/webmail supported by FireGPG) that supports PGP (a growing number) then at the very least, the noise gets hidden behind a “this message is signed” notice.

Few people want to read off long hex number to each other in person.  Here’s where it gets touchy, because anything we change here changes the security of the transaction.  I’m ok with that.  I’d rather my non-geek friends have a somewhat-trusted key than an untrusted key or no key at all.  My geek friends and I will still verify each others’ fingerprints.

Alice receives an email from Bob, with whom she has never previously shared cryptographic information.  Neither Alice nor Bob is a geek, tech savvy, or familiar with cryptography.  Alice knows her email program has a new feature that lets people verify each others’ messages and decides to try it out.

Alice elects to share her PGP key with Bob.

Alice has never shared her key with anyone before (she doesn’t have one).  She is told this and asked to wait while “some setup occurs”.  The key is generated and UI moves to the next step.  Somewhere in here there should be a notice to backup the key, “since if you lose it you can no longer send verified messages”. Public keys should be sent to a public key server automatically.

Alice secures her key to Bob.

Alice now picks a secure question and answer to prove to Bob (within a reasonable, but not cryptographically rigorous) measure of certainty.  An email is sent to Bob’s address with the output of `gpg -a –openpgp –export KEYID | gpg -ac –openpgp -` attached.  Also attached, it sends an unencrypted export of the public key, for use (moot in this case, on a new key) if this key has been signed by others Bob knows.  That is, Alice’s public key is symmetrically encrypted with an algoritm allowed by the OpenPGP standard (currently 3DES) with the passphrase as the answer to the secure question.  I’ve marked it case sensitive, but all UIs COULD downcase passphrases to simplify this.  The secure question becomes the body of the email and the subject can be something like “Alice is sharing her verification key with you!”

Bob recieves the email, an his client flags it (with an icon or similar) as containing verification information.  Some clients may find it makes more sense to process the message immidiately upon receipt, instead of just flagging it.

Bob opens (or his client auto-opens) the message.  Instead of being presented with an email full of gook, he is presented with a window by his client.

Bob decrypts the key.

Bob enters the answer and is presented with a window describing the key.  This window should say “Alice is claiming…” or similar and display the image in the key (if there is one) and all UIDs/comments.  There should then be a list of how well Bob knows this key:

It claims to be alice@example.com and was sent from there: very low

It was found to be the same as one available on public key servers: very low

It was verified using a secret question: medium

It has not been verified by anyone you know [aka, key signatures, high]

[Button: Advanced Verification, showing the key fingerprint – for advanced users]

[Button: trust this key]

[Button: I have talked to Alice and know this is her key (ultimate trust, signs key)]

If three or more signatures from people Bob trusts are on the key (remember, the unencrypted one) the client may skip to this step and provide a “verify using secret question” button.

Opening this message in the future should sync with keyservers, and then show the last dialog again, showing any new signatures from people Bob trusts, and allowing him to verify/sign it.

3 Responses

Denver Gingerich

Using PGP for authenticity assumes that the user will carefully protect their private key and no one else will be able to get it. This is a reasonable assumption to make when geeks are using PGP. However, for the average user, this is a fairly poor assumption to make. Most average users let others use their computer without supervision. Even if an average user was supervising someone else using their computer, they probably wouldn’t know if that person was stealing their private key.

Furthermore, average users are much more likely to send away their computer to get it fixed without removing any personal information. It would be simple for a computer repair person to steal identities as they repair computers.

When an average user migrates to a new computer, only important pieces of their data that they can easily see are copied from the old computer. Personalization settings tend to be lost since the user doesn’t know how to copy them to the new computer. I think a PGP key would get lost along with the personalization settings.

How do we get around these problems? The solution seems to be: make it server-side (yes, I’m cringing, too). The average user tends to understand that they should not give out their passwords. So it makes sense to have an authentication server, optionally separate from the mail server, that the user can connect to and store their key. The mail client would ask the authentication server to sign each message before sending it, prompting the user to enter their password (or sign in with OpenID) for each sent message (this could optionally be cached within the mail client session). It would make the most sense for webmail services to provide a built-in authentication server to simplify the process for users.

There are potential problems with this. One of these would be malicious authentication servers that steal private keys and use them to sign spam. In reality this probably won’t be an issue; as we have seen with popular webmail services, they tend to be trustworthy (though how much they analyze your data for trends is difficult to know).

We could also add a layer of indirection so that users could choose what sort of authentication they’d like to use: an authentication server, a local PGP key, or something else. This would make the system friendly for security freaks who like to have their PGP key stored on a physical medium they control.

Perhaps the real issue here is with PGP for average users where the key is stored on the user’s computer. If the key is stored in a secure place in the cloud, then the PGP authentication scheme will remain relatively secure even for average users. And, more to the point, Stephen’s suggestions remain valid with keys stored on an authentication server.

I’d be happy to get feedback on my suggestion and/or comments on the validity of my assumptions about average users.

Stephen Paul Weber

@Denver (1) users are inherently less secure that they should be… we can’t fix that, although I agree that trying is good. The ~/Private folder in Ibex should help this. (2) I do mention that users should be encouraged to back up keys (3) some sort of server-based storage of private key files may not kill us, since private keys are usually encrypted with CAST5, you could just ask the server for the private key file and decrypt it locally (4) re: webmail… feels evil unless users can be made to know about revocations (not having high hopes here…) (5) secure places in the cloud for public keys (like keyservers, but with OpenID/TLS for a bit better authz) integrated into social web stuff could prove useful

Leave a Response