Encrypted email is still a pain • Hacker News Board

Re: Encrypted email is still a pain

#351

Post by lmm » Mon, Feb 13, 2017, 11:32 PM UTC

rkeene2 wrote: post #244

lmm wrote: post #217

Earlier quoted context omitted.

a) The key management UX is even worse than GPG, at least IME. b) If you're willing to trust the CA system the advantages of using email rather than any transport-encrypted messenger (e.g. facebook messenger) seem decidedly marginal

You control which CAs you anchor your trust to locally. Additionally, the encryption part isn't tied to the CA system -- you encrypt directly with the public keys of your recipients. You can use the CA system to validate that the public key belongs to someone validated by some attributes -- certificates are used for this. The US Federal Government (FPKI) and US Department of Defense (DOD PKI) use S/MIME heavily.

> You control which CAs you anchor your trust to locally.

Theoretically, but doesn't it tend to use the same OS infrastructure as HTTPS?

> The US Federal Government (FPKI) and US Department of Defense (DOD PKI) use S/MIME heavily.

Indeed, but they are in a position to trust the US government (and more generally the international governmental system).

Re: Encrypted email is still a pain

#352

Post by lmm » Mon, Feb 13, 2017, 11:34 PM UTC

Certhas wrote: post #350

daptaq wrote: post #204

Earlier quoted context omitted.

The maintainer of the "Conversations" XMPP client wrote an interesting response to that article: https://gultsch.de/objection.html

Thanks, I wasn't aware of this. Though to be honest, I am not exactly convinced. Calling HTML federated seems a real stretch. My browser doesn't have to talk to other browsers, just servers, and those can speak many languages. The network effects are really _very_ fundamentally different. The reality is that, no matter how much I wanted xmpp (and google wave for that matter) to succeed, Signal (and if you are willing…

> And that's even though XMPP preceded Signal by a decade. The argument that a good federated user experience is possible in principle starts to sound a lot like talk about "sufficiently smart compilers".

For how much of that decade did we even see "a couple of full-time developers" applied to XMPP though? Yet alone an actual UX designer.

Re: Encrypted email is still a pain

#353

Post by lmm » Mon, Feb 13, 2017, 11:37 PM UTC

cdelsolar wrote: post #289

lmm wrote: post #172

Earlier quoted context omitted.

> What's the benefit of decentralization? Not being snarky, I just don't really see it. What does a decentralized PGP email have that I don't have with my Signal Messenger? It's a lot harder to block. You can have anyone run a mail server on any port (SSLed if necessary), which means you can use it for secure communications inside any "great firewall" (like that of China or Kazakhstan), or even in a country/region th…

Hm? if /BEGIN PGP SIGNED MESSAGE/.test(message) { greatFirewall.block(message); }

Sure, but that only catches messages that cross the wall. They could disconnect China from the Internet entirely, but email would still work within China.

Re: Encrypted email is still a pain

#354

Post by lmm » Mon, Feb 13, 2017, 11:38 PM UTC

Certhas wrote: post #182

lmm wrote: post #172

Earlier quoted context omitted.

> What's the benefit of decentralization? Not being snarky, I just don't really see it. What does a decentralized PGP email have that I don't have with my Signal Messenger? It's a lot harder to block. You can have anyone run a mail server on any port (SSLed if necessary), which means you can use it for secure communications inside any "great firewall" (like that of China or Kazakhstan), or even in a country/region th…

Also, is it really true that a state actor could not effectively block email? Or for that matter all encrypted email? They are, after all, blocking web pages. It seems to me (as a lay man observer) that at the state actor level the Internet is relying on centralized resources already, maybe that's why decentralization seems intuitively less important to me. This is not to disagree with your points.

They can block any traffic in/out of their network. But e.g. it's possible to use email on a LAN (or a wireless mesh network) entirely disconnected from the Internet.

Re: Encrypted email is still a pain

#355

Post by dijit » Mon, Feb 13, 2017, 11:38 PM UTC

Psilidae wrote: post #306

dijit wrote: post #44

Earlier quoted context omitted.

I'm glad S/MIME gets a mention because I've always been skeptical of it based on the fact that everyone rallies behind PGP. I recently failed to install gpg2 on freebsd (for some reason it barks at me and fails and I don't care enough to waste my time on it) and decided to give S/MIME a chance with a signed cert from comodo. (which was free, just to try) I have to say though the experience is beyond reasonable, it's…

Well, this just convinced me to snag a cert for myself. Are there any services like keybase for sharing S/MIME public keys?

No, that's the beauty. Once you emailed a person your validated cert is saved in their outgoing keychain.

No more public key exchange. I checked and Thunderbird often checks the CRL for the certificate I have. I also checked revocation of that certificate and thunderbird shows a big warning about it being invalid. (although it doesn't specify expired or revoked).

Re: Encrypted email is still a pain

#356

Post by lmm » Mon, Feb 13, 2017, 11:39 PM UTC

NoGravitas wrote: post #216

lmm wrote: post #209

Earlier quoted context omitted.

> But PGP-over-SMTP would still leak important metadata, and you would still have problems with forward secrecy and key revocation. I don't think a well-integrated PGP-over-SMTP client would leak any more metadata than the likes of Signal does? Build in a good subkey rotation config and you'd solve most of the forward secrecy issues, and good defaults for how to treat revocation (including better expiry defaults) wou…

You would still leak unencrypted headers, which in SMTP are numerous and interesting. A client could minimize the useful content of the message headers, but you're always going to have at least the envelope headers available to every intermediate mail host. I do not know enough to be sure about your point about forward secrecy. You may be right.

> you're always going to have at least the envelope headers available to every intermediate mail host.

Sure, so any intermediate server would see who was talking to who. But that's the case with Signal et al as well isn't it?

Re: Encrypted email is still a pain

#357

Post by a3_nm » Mon, Feb 13, 2017, 11:40 PM UTC

tptacek wrote: post #7

Encrypted email is pretty much over in 2017. The emerging consensus among experts is that it's not worth the trouble, or, worse, incapable of doing much more than generating a false sense of security. That's for a bunch of reasons: * An enormous installed base of clients that won't do encryption, meaning that at best you're attempting to tunnel encrypted messaging over an unencrypted transport. * A protocol that leak…

Despite "the emerging consensus among experts", I'm still happy using OpenPGP-encrypted emails (with mutt) with several of my friends and colleagues for various purposes. Of course the UX of GnuPG is terrible. Of course the security is not bullet-proof. Of course it's not for everyone. Yet I think it is a reasonable way to afford very strong security when we communicate, and it is extremely useful to us.

I don't think recent IM apps are a suitable alternative. Essentially all of these apps have young and unaudited code (assuming they are open source, which some aren't), and they are designed to run on phones with Google Play Services installed (i.e., a proprietary Google blob with complete access to the system), along with untrusted proprietary radio firmware from the phone manufacturer, all on a device with direct access to an untrusted cellular network. (Oh, and there is the issue that many things are inconvenient to do on phones, e.g., writing long emails. This wouldn't matter if these apps weren't essentially imposing a specific user interface on me, the way GnuPG doesn't. Oh, and many of these apps require a phone number, account creation on a specific provider, that I don't need for email, and that people can legitimately object to.)

By contrast GnuPG is ancient and well-tested code, running on computers, which mostly use free software, and which I trust much more than I trust my phone. I can do meaningful things on these computers, like writing long emails, coding, preparing confidential documents, that I essentially cannot do with a phone plus IM software.

Encrypted email has lots of drawbacks, sure, but it doesn't look to me like it is over. There are still lots of use cases for which there are no alternatives. And it's not because something isn't being used by everyone, or is less popular than other solutions, that it is not useful for some people, or that it won't last.

Re: Encrypted email is still a pain

#358

Post by epistasis » Mon, Feb 13, 2017, 11:40 PM UTC

lmm wrote: post #351

rkeene2 wrote: post #244

Earlier quoted context omitted.

You control which CAs you anchor your trust to locally. Additionally, the encryption part isn't tied to the CA system -- you encrypt directly with the public keys of your recipients. You can use the CA system to validate that the public key belongs to someone validated by some attributes -- certificates are used for this. The US Federal Government (FPKI) and US Department of Defense (DOD PKI) use S/MIME heavily.

> You control which CAs you anchor your trust to locally. Theoretically, but doesn't it tend to use the same OS infrastructure as HTTPS? > The US Federal Government (FPKI) and US Department of Defense (DOD PKI) use S/MIME heavily. Indeed, but they are in a position to trust the US government (and more generally the international governmental system).

>Indeed, but they are in a position to trust the US government (and more generally the international governmental system).

Not sure what trusting the government has to do with it, it has to do with trusting the CA system that's set up on the computer.

Re: Encrypted email is still a pain

#359

Post by [deleted] » Mon, Feb 13, 2017, 11:40 PM UTC

lmm wrote: post #351

rkeene2 wrote: post #244

Earlier quoted context omitted.

You control which CAs you anchor your trust to locally. Additionally, the encryption part isn't tied to the CA system -- you encrypt directly with the public keys of your recipients. You can use the CA system to validate that the public key belongs to someone validated by some attributes -- certificates are used for this. The US Federal Government (FPKI) and US Department of Defense (DOD PKI) use S/MIME heavily.

> You control which CAs you anchor your trust to locally. Theoretically, but doesn't it tend to use the same OS infrastructure as HTTPS? > The US Federal Government (FPKI) and US Department of Defense (DOD PKI) use S/MIME heavily. Indeed, but they are in a position to trust the US government (and more generally the international governmental system).

[deleted]

Re: Encrypted email is still a pain

#360

Post by zeveb » Mon, Feb 13, 2017, 11:45 PM UTC

coldtea wrote: post #304

zeveb wrote: post #293

Earlier quoted context omitted.

You don't know any deadbeats you trust less than a random person selected from the population at large?

The "web of trust" is not about trusting everybody you happen to merely know. It's, and the name is kind of a hint, about knowing those you trust -- it's a web in that there's higher level trust (people you personally know and trust yourself), secondary trust (people trusted by those you trust), etc. And in cryptography it's even more specific: https://en.wikipedia.org/wiki/Web_of_trust It's not in any way about trus…

Point, but I'll refer you to my following sentence: 'The fact that I trust you to vouch for employees of Acme Widgets means nothing about whether I trust you to vouch for members of a political party.'

The Web of Trust assumes that I trust anyone to vouch for everyone (interesting, TLS — itself also a product of 1990s crypto-thinking — makes the same assumption). But I simply don't. I don't trust my nearest & dearest family & friends to vouch for every identity I care about. But I do trust some of them for some identities.

I trust myself to validate possession of any key. I trust my employer to validate possession of keys related to its work, but not keys related to, e.g., my family or my blog. I may trust one of my brothers to validate keys related to his immediate family, and maybe I trust two of my brothers to jointly validate keys related to our family, but I don't trust them for work, or my blog. I may trust my blogging co-admins to validate keys for roles in the blog, but that doesn't mean they get to validate keys for identities at my employer, or validate keys on behalf of my parents or children.

I could use different email addresses for each identity (I-the-employee, I-the-son, I-the-blogger), and have each identity trust only those who are pertinent to it, but that makes PGP more, not less, difficult. And it's certainly not the model that PGP advocates.