Live data from Hacker News

I'm giving up on PGP

blog.filippo.io

211–220 of 350 posts

Re: I'm giving up on PGP

#211
The 'deficiency' of PGP lay in the leaky nature of the computer itself. How do you maintain your all important private keys? On disk? In memory? USB? All are leaky from the get go. And this, I posit, is the problem gents.

Re: I'm giving up on PGP

#212
post #32

Earlier quoted context omitted.

> I wonder if pgp is fundamentally flawed, or we have a deep conceptual usability issue here. I don't think the "WoT" is conceptually flawed, and frankly, the argument that "people of average intelligence" can't grasp the concept comes from a very high horse and is also untrue. It's simply that any and all software for PGP utterly fails in the UX and functionality department when it comes to key management. Web of Tr…

I have to partially disagree with that. Calling PGP an utter failure is an understatement. Just like calling a cat a small tiger. PGP is possibly the WORST experience in usability for any well known software that ever lived. This thing should be taught in courses for decades to come as how to fail a product by 1) having no UI 2) no integrations with anything 3) zero usability 4) not even trying to give a fuck about n…

Really? Which national government? Why wouldn't they backdoor it?

Re: I'm giving up on PGP

#213
post #193
post #32

Earlier quoted context omitted.

> I wonder if pgp is fundamentally flawed, or we have a deep conceptual usability issue here. I don't think the "WoT" is conceptually flawed, and frankly, the argument that "people of average intelligence" can't grasp the concept comes from a very high horse and is also untrue. It's simply that any and all software for PGP utterly fails in the UX and functionality department when it comes to key management. Web of Tr…

I worked in IT for an engineering company that required all external emails to be PGP encrypted. Despite all engineers having Symantec PGP software installed and setup, training, and support of IT, they would often ignore this policy. The excuse, often valid, was it would require IT from both companies to setup the encrypted keys for the first time for new users. If the system is too complex for engineers, the idea o…

Well-run email clients and servers are in an OK state today regarding encryption, and the weaknesses that exist are more related to adoption than technology. Take a typical office setup: your email client communicates over TLS with your central mail server (e.g. Exchange, Postfix) to retrieve or submit messages. This is true with webmail clients like Gmail and Outlook Web Access, as well as ones like Outlook/Mail.app/etc.

When sending or receiving email from other organizations, your mail server will communicate over TLS as well. Virtually all ISPs support TLS-protected SMTP today, and if you run your own server you can set it up easily enough. Google's Safer Email Transparency Report publishes statistics about the percent of encrypted email between Gmail and other top email ISPs [1]. TLS wasn't always widely supported in the past -- just as with web servers -- but any modern installation today will support TLS.

Modern email installations and usage are secure against passive surveillance as well as HTTPS. Where email is still weak is in its usage of opportunistic TLS (still common if not the default). An adversary capable of conducting a man-in-the-middle attack can force connections to fall back to plaintext, or can present a bogus self-signed certificate since many servers and clients do not expect a path-validated certificate.

There are defenses against those attacks, though. You can configure your SMTP server to require TLS, and to accept only path-validated TLS certificates from trusted certificate authorities. This will prevent an adversary from forcing your traffic to plaintext, and will prevent them from substituting a bogus self-signed certificate. With these protections in place, one can achieve a fairly good measure of security with basic email.

This is not to say that email is suitable in all circumstances. For high sensitivity use-cases one should consider attacks on infrastructure like the mail server: as we saw in this year's political campaigns, mail servers can be a trove of confidential information. One benefit of the GPG approach is that the mail server does not need to be trusted with the confidentiality of the communication, and so cannot compromise it.

[1] https://www.google.com/transparencyreport/saferemail/ The systems that show up as plaintext in this report are largely older commercial bulk email sending systems; all consumer-oriented ISPs adopted TLS a while back.

Re: I'm giving up on PGP

#214
post #98

I find very interesting the point about the split between what WoT was supposed to be, in theory, and what little it represents, in practice, in terms of practices about key verification. It has been said many times that the lack of adoption of pgp in mail was due to the average user not being able to grasp the concepts behind the proper operation for key management, but the article points to common practices among "…

Is there anything that enables key exchange via smartphones? Ideally it should be as easy as a meatbag handshake. Basically, if you can swap contacts via NFC then the pgp keys should go along with it. It may have some theoretical weaknesses such as the exchange being MITMable if the users don't verify something on their screens, but I think having many more edges in the graph would make up for it since you might alre…

So not really for iOS :/

Re: I'm giving up on PGP

#215

The conclusions here (avoiding long-lived per-identity keys and having the option to easily rotate and re-validate per-device keys) are very much what we've aimed for in the end-to-end crypto for Matrix.org ( https://matrix.org/blog/2016/11/21/matrixs-olm-end-to-end-en... ). Rather than using a silo like Signal or WhatsApp, it is possible to get the flexibility of an open federated network built on an open standard,…

IMHO, the biggest issue with matrix, is that there's no free hosted solution for using my own domain/email.

Sure, I can rent a server and set up my own, but that's a huge commitment to "try out" a protocol which non of my acquaintances uses yet.

Re: I'm giving up on PGP

#216

Earlier quoted context omitted.

I have to partially disagree with that. Calling PGP an utter failure is an understatement. Just like calling a cat a small tiger. PGP is possibly the WORST experience in usability for any well known software that ever lived. This thing should be taught in courses for decades to come as how to fail a product by 1) having no UI 2) no integrations with anything 3) zero usability 4) not even trying to give a fuck about n…

Really? Which national government? Why wouldn't they backdoor it?

Any government who wants to bring 2FA to its citizens.

Shipping a national backdoor is an entirely different topic. Please focus on the use case at hands.

Re: I'm giving up on PGP

#217
So, to distinguish, there's web-of-trust things and general pgp/gpg encryption (and signing) UX. Both of these are pretty abysmal for non-technical users.

I don't think "muggle" users would be interested in the web of trust at all, and I doubt they can really handle it all that well. But I'm a pretty technical person (MS in Computer Science, PhD in a different field), and well:

http://keyserver.ubuntu.com/pks/lookup?op=vindex&search=eric...

I don't think the web of trust really matters- would you look at that and say, "hey, this Eric fellow has a 2004 key for his gmail, and an unrelated 2016 one, I'd better not trust him." Doubtful.

Honestly, in today's internet (I know, dangerously political...) I think there should be a stronger move toward broad-spectrum encryption of all emails. I actually generate trust with most of my email correspondents independently, but I sure would like to encrypt my communication. Signal is good for shorter messages, but email is still email.

It isn't like I have state secrets in my email, but I do have stuff I don't want random government snoops reading, especially if they're bulk-collecting. Furthermore, I think it's important for more people (even people who don't need it) to encrypt their correspondence, so we can provide cover for people who really do need it. Journalists and dissidents won't stand out as much if everybody is encrypting.

To that end, I think pgp / gpg is still pretty cruddy for UX. There are decent solutions for each platform, but nothing really good, and my friends / family aren't likely to use a mail client or webmail that's not at least almost as good as gmail/inbox just because I am worried about privacy.

I've recently moved to protonmail for most mail, since it has a very slick user experience and I want to know it well enough to be able to recommend it to other people. However, protonmail doesn't let me have my private key (or its analogue - I'm not 100% sure how things really work, but I have a public key that I can give to other people, and those other people can send me encrypted stuff from off-platform. I just can't reply in the same fashion). That means if I lose my protonmail account, woops, I can't read the emails you sent me encrypted to my @protonmail.com account, even if I get the emails. This is more of A Thing now that you can set up protonmail as your MX, and therefore get emails addressed to domains you control on the platform - if I ever swapped my personal domain around, I'd like to have the key.

So, for end-to-end encrypted simple messages, signal is great. I just wish protonmail did interop, and then I'd really recommend it to other people.

Re: I'm giving up on PGP

#218
post #32

Earlier quoted context omitted.

> I wonder if pgp is fundamentally flawed, or we have a deep conceptual usability issue here. I don't think the "WoT" is conceptually flawed, and frankly, the argument that "people of average intelligence" can't grasp the concept comes from a very high horse and is also untrue. It's simply that any and all software for PGP utterly fails in the UX and functionality department when it comes to key management. Web of Tr…

I have to partially disagree with that. Calling PGP an utter failure is an understatement. Just like calling a cat a small tiger. PGP is possibly the WORST experience in usability for any well known software that ever lived. This thing should be taught in courses for decades to come as how to fail a product by 1) having no UI 2) no integrations with anything 3) zero usability 4) not even trying to give a fuck about n…

Why the fuck would you ever insert a government-provided USB key into any computer you actually cared about, much less actually use any government-provided key? The national government is the prime adversary. I mean, seriously, Alice and Bob want to communicate, and your solution is that they should use Eve as a courier!??

Re: I'm giving up on PGP

#219
post #206
post #193

Earlier quoted context omitted.

I worked in IT for an engineering company that required all external emails to be PGP encrypted. Despite all engineers having Symantec PGP software installed and setup, training, and support of IT, they would often ignore this policy. The excuse, often valid, was it would require IT from both companies to setup the encrypted keys for the first time for new users. If the system is too complex for engineers, the idea o…

99% of crypto would work just fine if you appended an OTR-like protocol over the top of email. First email is "hey we're interested in blah..." and is sent in the clear. Then have the message window change color as subsequent emails get the protocol more secured.

I hate color coding. I'm in the 8-12% of men that have red-green deficient vision. You can use 10% as a rule of thumb. If I'm not mistaken in my probability math, that means in a group of 5 men, there is a 50% chance one of them is "color blind."

Yet the world insists on using red/green as bad/good indicators. Drives me nuts.

Re: I'm giving up on PGP

#220

Earlier quoted context omitted.

Really? Which national government? Why wouldn't they backdoor it?

Any government who wants to bring 2FA to its citizens. Shipping a national backdoor is an entirely different topic. Please focus on the use case at hands.

I think that issue is central. You're describing a scheme with a central, trusted authority distributing keys. The question is, what's a central authority we can all trust? I think many people wouldn't trust any government. At that point, the design crumbles.
Post reply on HN