Live data from Hacker News

Encrypted email is still a pain

incoherency.co.uk

341–350 of 450 posts

Re: Encrypted email is still a pain

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

>* 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. All encrypted communication on the internet is 'attempting to tunnel encrypted messaging over an unencrypted transport.' That's literally the entire point. I don't care that my messages are broken down into unencrypted IP packets, because my messages ar…

Why would I take the time to answer any of your questions? You just wrote upthread that, because I have a background in security consulting, everything I write must be designed to cause security problems so I can line my pockets.

No thanks.

Re: Encrypted email is still a pain

#342
post #189
post #170

Earlier quoted context omitted.

> The emerging consensus among experts "conseunsus"? a few blog posts about some bad user experience with GnuPG / the PGP ecosystem is, at best, just an (re)emerging topic on HN, not the end of email encryption. OpenPGP implementations may not be the easiest encryption software out there (its usability issues have been discussed for two decades now) but that's simply because PGP was not designed to be used by the lai…

There are federated options for messengers, the fact that the current darlings aren't is not a mark against the option itself. Riot exists. Can you find a security expert RECOMMENDING email? That would be a better example of how it's not a consensus, like you claim.

As far as I can tell, encrypted email is still how you reach out to CERT, security teams at distros such as Ree Hat, Debian and so on?

These people might not be crypto experts, but hopefully many of them are security experts.

Gpg is also how most mailing list communication is (clear-)signed - and that coupled with public archives does give a way to verify that the person that controls the key that signed release notes for this package these last five years, is the person that will be able to read this zero-rated report that is critical. (It says very little about said owners real identity, or his or her legal name)

What does FreeBSD, OpenBSD or Oracle recommend for sending sensitive information to security@?

That said, modern email suck.

Mutt (possibly with "not much") might "suck less" - but we need many more, better (graphical) email clients. I think Fastmail's work on a json-based client protocol is interesting (not because it's json, but because every blank staring IMAP-client writing developer keep saying that there are terrible horrors laying in ambush for the unwary).

Opera had a nice, new-ish, fast mail client. Other than that I'm unaware of any serious effort to make a new, modern, easy to use IMAP client. Let alone an open source one. Or one that doesn't beg to expose library bugs by rendering html, images etc in-line - or ignore user privacy by loading external resources that enable user tracking.

I've been contemplating writing one for quite some time.

Re: Encrypted email is still a pain

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

I'm having the impression your friendship with moxie is altering your judgement. Signal and Whatsapp are not a solution for everything and will certainly not replace email.

Moxie and I are barely acquaintances.

Re: Encrypted email is still a pain

#344

Years ago, working at a friend's security company everyone used Apple Mail with GPG. That is the only time anyone insisted on using encrypted email. Fast forward to the present: I support and like ProtonMail, but I can't talk anyone else into using it. I don't understand why more small companies, wanting to protect their intellectual property, don't use ProtonMail (or something like it).

Well, AFIAK ProtonMail doesn't have business accounts yet, they say they will be adding them soon though.

Re: Encrypted email is still a pain

#346
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.

It's more that a private actor can exclude you from any network. Maybe WhatsApp blacklist you for "abuse". Maybe they're right. But even if you kill someone you're allowed to use the telephone network, and send or receive letters.

As long as the message silos aren't regulated as utilities, decentralised systems give us more of the freedoms.

It's pretty easy to run a separate dns system - you can even blend your own private "authorities" dns for new tlds with fall back to the centralised root servers.

Re: Encrypted email is still a pain

#347
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.

Depends a bit what one considers integration:

https://en.m.wikipedia.org/wiki/Anonymous_remailer

Re: Encrypted email is still a pain

#349
post #31

For what it's worth, I used to use encrypted mail some time ago as much as possible, before realising it was fundamentally flawed: — the key retention is the biggest issue. You need to keep your key around for a long time, probably storing copies of it. This increases the probability of a leak. — there is no method to revoke a key with a 100% assurance that nobody will use or trust it afterwards. — if a key is broken…

If you want archiving, store "plain text" mail on an encrypted disk/along with your other encrypted backup?

You will need to archive the public and private keys if you need to go back and audit messages - but that assumes that "I verified to my satisfaction in 1996 and archived securely" isn't enough.

Re: Encrypted email is still a pain

#350
post #204

Earlier quoted context omitted.

https://whispersystems.org/blog/the-ecosystem-is-moving/ One of the explicit protocol level trade offs is federation: > One of the controversial things we did with Signal early on was to build it as an unfederated service. Nothing about any of the protocols we've developed requires centralization; it's entirely possible to build a federated Signal Protocol based messenger, but I no longer believe that it is possible…

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 to trust the closed source client WhatsApp) are the only ones that did.

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".

Let's grant it is true that we don't have sufficient resources to update a host of different clients to use all the extensions. So then it still seems that in a resource constrained environment federation is not feasible. Open Whisper Systems managed to get encryption on a billion devices with a team of three people. The idea that it only succeeded due to a resources advantage (rather than fundamentally different trade-offs) does not seem very plausible.

Post reply on HN