Live data from Hacker News

Why Johnny Still Can't Encrypt: Evaluating the Usability of a Modern PGP Client

arxiv.org

61–70 of 165 posts

Re: Why Johnny Still Can't Encrypt: Evaluating the Usability of a Modern PGP Client

#61
It's worth mentioning, the original paper [0] recently won the USENIX Security 2015 Test of Time Award [1], which highlights papers at least 10 years old, that have made a lasting impact on their field.

[0]: http://www.gaudior.net/alma/johnny.pdf

[1]: https://www.usenix.org/conferences/test-of-time-awards

Re: Why Johnny Still Can't Encrypt: Evaluating the Usability of a Modern PGP Client

#63

I see two major barriers to mass adoption of any crypto system that requires a UI. 1. Abstraction. For the non-expert, the only metaphor that works for PKI is that of physical security. The concept of a "key" as a series of characters or a file that must be protected must be replaced by an abstraction that allows users to protect it in the same way they understand how to protect a key or a wallet. So long as the "key…

I agree that some terminology could make it easier. I think "key" is an ok choice for the private key, but for the public key I think there could be a better analogy. Calling them the same thing is a bit confusing and people don't understand that one of them you give away, while the other is confidential.

When I explain it to people I tell them that their public key is like an unlocked lockbox that you give people into which they can put a private message. They can close the box to lock it, but once they shut the box only you have the key to open it.

It's not a great analogy but it seems to me that the public key does not make sense as a "key" to the average person.

Re: Why Johnny Still Can't Encrypt: Evaluating the Usability of a Modern PGP Client

#64

I see two major barriers to mass adoption of any crypto system that requires a UI. 1. Abstraction. For the non-expert, the only metaphor that works for PKI is that of physical security. The concept of a "key" as a series of characters or a file that must be protected must be replaced by an abstraction that allows users to protect it in the same way they understand how to protect a key or a wallet. So long as the "key…

> 1. Abstraction. For the non-expert, the only metaphor that works for PKI is that of physical security. The concept of a "key" as a series of characters or a file that must be protected must be replaced by an abstraction that allows users to protect it in the same way they understand how to protect a key or a wallet.

Do you mean something like the Yubikey USB dongle: https://www.yubico.com/products/yubikey-hardware/

[not associated, just referencing a 'physical' item that can be treated as a 'key' by non-experts]

Re: Why Johnny Still Can't Encrypt: Evaluating the Usability of a Modern PGP Client

#66

I see two major barriers to mass adoption of any crypto system that requires a UI. 1. Abstraction. For the non-expert, the only metaphor that works for PKI is that of physical security. The concept of a "key" as a series of characters or a file that must be protected must be replaced by an abstraction that allows users to protect it in the same way they understand how to protect a key or a wallet. So long as the "key…

I agree that some terminology could make it easier. I think "key" is an ok choice for the private key, but for the public key I think there could be a better analogy. Calling them the same thing is a bit confusing and people don't understand that one of them you give away, while the other is confidential. When I explain it to people I tell them that their public key is like an unlocked lockbox that you give people in…

I think if it can be made to work, a better framing is in terms of establishing a secure channel and then communicating/sharing something over that channel.

Don't make the user think about the underlying mechanism at all.

The hardest part is probably getting the public key distributed, but that can just be "Check if Bill can receive over a secure channel."

Re: Why Johnny Still Can't Encrypt: Evaluating the Usability of a Modern PGP Client

#67

I see two major barriers to mass adoption of any crypto system that requires a UI. 1. Abstraction. For the non-expert, the only metaphor that works for PKI is that of physical security. The concept of a "key" as a series of characters or a file that must be protected must be replaced by an abstraction that allows users to protect it in the same way they understand how to protect a key or a wallet. So long as the "key…

I've been using GPG since a while now, to sign my outgoing mail. I don't encrypt it as I don't know anyone who uses GPG. I'm still happy to use it, to get used to it, and to see alternative uses. Signing is in my view a big improvement, to make sure nobody has messed with the messages. I always use HTML, so the receiver gets an attachment with the signing hash in it, and no strange text in the mail. I use a signature with a link to my public key and a link to the PGP page on Wikipedia. Everybody can read my mail, and if they want they can validate it.

Re: Why Johnny Still Can't Encrypt: Evaluating the Usability of a Modern PGP Client

#68

I see two major barriers to mass adoption of any crypto system that requires a UI. 1. Abstraction. For the non-expert, the only metaphor that works for PKI is that of physical security. The concept of a "key" as a series of characters or a file that must be protected must be replaced by an abstraction that allows users to protect it in the same way they understand how to protect a key or a wallet. So long as the "key…

See "Why King George III Can Encrypt" (2014) for an alternative metaphor to 'private key' and 'public key':

http://randomwalker.info/teaching/spring-2014-privacy-techno...

>We present the user with four items, a key, lock, seal and imprint. The key and lock serve the purposes of encryption: Alice distributes her locks as widely as possible so that others can send her messages that only she can open with her key. Similarly, the seal and imprint handle signing: Alice passes out copies of her imprint so others can verify her as the sender of messages she has stamped with her seal. Collected together, we refer to these four items as a toolkit this abstraction handles the contingency where a user loses her key but not her seal: we insist that the toolkit represents an indivisible unit that must be replaced whenever any element is lost.

Re: Why Johnny Still Can't Encrypt: Evaluating the Usability of a Modern PGP Client

#69
post #46

Backwards compatibility is the killer. The whole design of PGP is to be the envelope to make email private, versus the plaintext postcard that everybody can read. It works with existing servers and existing mail clients. The biggest Snowden revelation is the importance of metadata. Just knowing whom you talk to, when, is frequently enough to compromise the parties involved. You might be doing something legal now, but…

> In practice, I heard someone say that the biggest improvement in people’s privacy has been use of Gmail.

In practice, until Snowden happened, NSA was able to access all the Google's internal data as Google replicated in plaintext its whole datacenters through the links snooped by the NSA or the GCHQ.

http://www.slate.com/blogs/future_tense/2013/10/30/nsa_smile...

Re: Why Johnny Still Can't Encrypt: Evaluating the Usability of a Modern PGP Client

#70
post #67

I see two major barriers to mass adoption of any crypto system that requires a UI. 1. Abstraction. For the non-expert, the only metaphor that works for PKI is that of physical security. The concept of a "key" as a series of characters or a file that must be protected must be replaced by an abstraction that allows users to protect it in the same way they understand how to protect a key or a wallet. So long as the "key…

I've been using GPG since a while now, to sign my outgoing mail. I don't encrypt it as I don't know anyone who uses GPG. I'm still happy to use it, to get used to it, and to see alternative uses. Signing is in my view a big improvement, to make sure nobody has messed with the messages. I always use HTML, so the receiver gets an attachment with the signing hash in it, and no strange text in the mail. I use a signature…

Getting a strange attachment is better then getting a few strange lines of text at the end of the email?
Post reply on HN