Live data from Hacker News

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

arxiv.org

51–60 of 165 posts

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

#51
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…

SMTP with TLS doesn't leak any metadata except the connecting IP address. And with DMARC you can mandate it.

Calls for whole new protocols for email are usually made by people who don't understand the email ecosystem as it currently stands.

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

#52
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…

SMTP with TLS doesn't leak any metadata except the connecting IP address. And with DMARC you can mandate it. Calls for whole new protocols for email are usually made by people who don't understand the email ecosystem as it currently stands.

Can the TLS be enforced by the sender all the way through the chain to the destination mailbox?

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

#53
post #37

Real secure encryption is and always will be not user friendly because it means only you can know the private key. This means no "Forgot my password" functionalities, no fancy powerful cloud AI analyzing your data and suggesting cool stuff, no free hosted full text search of your data, no open directory of friends to search on etc. So basically, no gmail, icloud, facebook, dropbox etc. It would require a complete new…

Because I have no interest in memorizing keys, I store them on disk protected by a passphrase. I don't know if this counts as "Real secure encryption" but it's sure a lot more secure than more typical use of email.

You can store it on disk protected by a passphrase but that's still not user friendly as way too few people would be willing to or capable of doing so which was my main point. My point is that secure encryption is by definition impractical, inconvenient and not user friendly which makes its adoption by mainstream users very unlikely at least in the foreseeable future.

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

#54

Earlier quoted context omitted.

SMTP with TLS doesn't leak any metadata except the connecting IP address. And with DMARC you can mandate it. Calls for whole new protocols for email are usually made by people who don't understand the email ecosystem as it currently stands.

Can the TLS be enforced by the sender all the way through the chain to the destination mailbox?

Yes, as well as PGP or S/MIME. It just depends or your relay configuration. We've implemented it switch able. We've customers that are bouncing non PGP encrypted E-Mails.

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

#56

Earlier quoted context omitted.

SMTP with TLS doesn't leak any metadata except the connecting IP address. And with DMARC you can mandate it. Calls for whole new protocols for email are usually made by people who don't understand the email ecosystem as it currently stands.

Can the TLS be enforced by the sender all the way through the chain to the destination mailbox?

The sender (the sender's service provider or organization) decides when to use TLS while the message bounces around internally, then (this is the typical long hop) the recipient's server and the sender's SMTP client negotiate, and then the recipient gets to decide.

The sender may have opinions, but as soon as the message is handed over to the recipient's server, that's it. That's the end of the sender's influence, and that's how it has to be on a global internet. People can connect without having their infrastructure approved by anyone else.

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

#57
post #55

What ever happened to Google's "End-To-End" Chrome extension? https://googleonlinesecurity.blogspot.com/2014/06/making-end...

It's still being worked on. Turns out, getting these things right from a crypto and a UX perspective is hard.

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

#58
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…

SMTP with TLS doesn't leak any metadata except the connecting IP address. And with DMARC you can mandate it. Calls for whole new protocols for email are usually made by people who don't understand the email ecosystem as it currently stands.

But SMTP with TLS is opportunistic -- and if we're talking "national state secrets" it's trivial for a state to MITM the connection and do a TLS downgrade attack.

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

#60
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" continues to appear to be an enormous password, people will continue to treat it that way, along with all the crazy worst-practices in the world. Not to mention the huge host of problems that accompanies key security for the layman.

I don't know what the answer is, but I do think that a physical token of some sort is the right start.

2. At the end of the day, the vast majority of people are not interested in the trade off between better security and convenience.

There is a learning curve, however shallow it can be made, and those that genuinely want or need better security are motivated enough to do the learning. For everyone else, it's like optional homework.

I would add to this that most everyone I know who cares about security is quite comfortable with a large array of APIs and software to do all sorts of cryptographic gymnastics. The bar is quite low already -- it has been for some time, IMO.

Post reply on HN