Convenient End-To-End Encryption for E-Mail • Hacker News Board

Re: Convenient End-To-End Encryption for E-Mail

#101

Post by dredmorbius » Sun, Jan 07, 2018, 8:58 AM UTC

sjwright wrote: post #72

slavik81 wrote: post #25

Earlier quoted context omitted.

There shouldn't be any difference. When opening it in a web page, you're just running it in the browser's sandbox. How did it come to this? It seems like the web browser is doing the operating system's job. Were OS vendors just asleep at the wheel? My pet theory is that OS vendors didn't really need a good sandbox. They could just tell you to be careful what applications you run. But, nobody would accept web browser…

It's the operating system's job to protect itself from userland, as well as to protect userland from other userlands. It's generally not its job to protect your documents from your applications. Normal people don't worry about malware rooting their OS. Normal people worry about malware ruining their un-backuped photos and work docs, something that few operating systems dare protect users from. (Which is why the iOS m…

Except that we went through this in the 1990s and:

1. Highly-interactive, programmatic, cross-connected documents were (security-wise) a Very Bad Thing.

2. Secure systems divorced viewing of documents from either editing them or running code. Mostly.

Windows didn't do this, and ended up with massive security issues, but the systems were largely not massively interconnected. Yes, they were on business LANs, and yes, there were connections to some other systems (largely through email), but not today's "everything is on the Web and you're connecting to 100s or 1,000s of remote sites daily".

Unix systems, generally, did enforce separation. They were also typically more interconnected (remote filesystems, ftp, telnet, early SSH, early Web), but there was some sanity in data/code separation.

Unix systems could produce and view Postscript and PDF documents. Windows systems ... mostly couldn't. If you wanted to view a Word document, you either printed it out, or you opened it in MS Word.

Microsoft did, yes, make a read-only viewer application. If you tried to, say, scroll through a document by hitting the spacebar, it would pop up a dialog telling you you couldn't edit the document. Every. Fucking. Time. You. Hit. Space.

I nuked that mofo so fast. "less" with catdoc or mswordview worked well enough for me.

I'm not claiming that 1990s Unix / Linux systems had sufficient process/data separation or sandboxing for today's network environments. They didn't (and we've got the scars to show for it). But they were following a more appropriate tack, and did in general foster environments where documents weren't openly dangerous.

(Again: mostly, there were exceptions, but they also pushed limits and took things in directions that weren't generally intended by the software designers, in sharp contrast to Windows.)

Re: Convenient End-To-End Encryption for E-Mail

#102

Post by dredmorbius » Sun, Jan 07, 2018, 9:05 AM UTC

tptacek wrote: post #8

Unpopular but very probably true fact: email can't practicably be made secure, and people should stop trying. Email is itself archaic, and there aren't good reasons people should use it for routine peer-to-peer communications that need secrecy. Why? Because: * It's default-plaintext. We don't generally love the way websites ensure they're viewed securely, but email doesn't even have the basic mechanisms HTTP has to p…

Let's accept all this as true. (I've got some quibbles, but agree in general form.)

1. What's the alternative look like?

2. How do we get there from here?

If you've a prepared piece on this (or someone else's that you largely agree with), that would be great to point at.

If you don't, I'd very much like to see something.

I've been trying to keep vaguely on top of email and messaging protocols and failing massively. My own view is that SMTP email probably is done for, though there may be some Good Bits to salvage, and most definitely some Hard Lessons to retain.

Re: Convenient End-To-End Encryption for E-Mail

#103

Post by dredmorbius » Sun, Jan 07, 2018, 9:08 AM UTC

tedunangst wrote: post #17

ekianjo wrote: post #12

Earlier quoted context omitted.

> Lose that key, ever, and not only is every message you send in the future unsafe, but every message you've ever sent in the past is too. That's a terrible property for a secure messaging system. That's false. There are mechanisms for lost keys revocation. This is already a solved problem. > Email leaks metadata. In fact, some of what we call email "metadata" isn't even metadata --- stuff like subject lines are simp…

> That's false. There are mechanisms for lost keys revocation. This is already a solved problem. This is very dangerously wrong. Revoked keys decrypt old data just fine. Revocation is advisory. Your attacker will choose to disregard that advice and decrypt anyway. > And Email has a lot more benefits than your typical IM - it's a standard after all and can be used every everyone on Earth, you don't need to rely on any…

The keyholder can re-key / re-encrypt messages they hold against the new key(s).

Obviously: they cannot re-key / re-encrypt messages they don't hold that were encrypted against the now-untrusted key.

Do you see any ways around that? Doesn't key-based encryption of long-duration data intrinsically have this limitation?

Re: Convenient End-To-End Encryption for E-Mail

#104

Post by a3_nm » Sun, Jan 07, 2018, 9:09 AM UTC

chakalakasp wrote: post #67

ekianjo wrote: post #32

Earlier quoted context omitted.

> It's that we should stop using email pretty much altogether. Like I said: it's archaic Sorry but have you ever used Signal or any other IM to send anything longer than a few sentences? Email can be as long as you want, and it is totally appropriate when you want to write a longer document.

Yes, you can write as long a message as you want with signal. There are desktop clients. You can attach files. Or voice messages. Or use it to call them. Or video chat them. It’s a crazy robust full featured incredibly secure communications system.

It's a centralized system, with a single point of failure, and you cannot use it without a phone number.

Re: Convenient End-To-End Encryption for E-Mail

#105

Post by a3_nm » Sun, Jan 07, 2018, 9:16 AM UTC

tptacek wrote: post #27

mapgrep wrote: post #22

Earlier quoted context omitted.

Your dimissive post boils down to “less than 100% perfect security is not ‘practicable’ so let’s leave a massively used, default communication platform utterly unsecure.” At least three of your critiques of encrypted email could be made of HTTPS: it leaks metadata (what sites you visit and when), it is plaintext by default, and the archives of the secured material are persistent and searchable. Yet HTTPS is hugely va…

You seem to be relishing this takedown post. I don't want to harsh on that, since I enjoy writing a takedown as much as anyone, but I have to point out that you're attacking an argument I didn't make. It's not my argument that people should use special secure messaging applications when they need security, and email at other times. It's that we should stop using email pretty much altogether. Like I said: it's archaic…

> a lot of us look at our email inboxes these days and notice that most of what's in there is automated transactional stuff, with occasional cold inbound introductions that quickly transition off into some better medium

Just wanted to point out: that's certainly not true for everyone. The overwhelming majority of my work communication is done by email, and an important part of my social communication with friends and family also is. Yes, even with long-time colleagues and friends. Not everyone is using, or wants to use, other messaging applications.

> It's that we should stop using email pretty much altogether.

Is there another communication system that is decentralized (no single point of failure, no central place where people have to register, I can run my own server and customize the client), and is also widely used?

Re: Convenient End-To-End Encryption for E-Mail

#106

Post by Canada » Sun, Jan 07, 2018, 9:18 AM UTC

tptacek wrote: post #8

Unpopular but very probably true fact: email can't practicably be made secure, and people should stop trying. Email is itself archaic, and there aren't good reasons people should use it for routine peer-to-peer communications that need secrecy. Why? Because: * It's default-plaintext. We don't generally love the way websites ensure they're viewed securely, but email doesn't even have the basic mechanisms HTTP has to p…

I predict autocrypt will get basically zero adoption because no mail clients with significant user bases will bother with it, and the rest are web apps anyway.

It would be nice if there were a signal client that looked like an email client, organizing messages by subject rather than conversation partner.

Re: Convenient End-To-End Encryption for E-Mail

#107

Post by Gatsky » Sun, Jan 07, 2018, 9:54 AM UTC

tptacek wrote: post #8

Unpopular but very probably true fact: email can't practicably be made secure, and people should stop trying. Email is itself archaic, and there aren't good reasons people should use it for routine peer-to-peer communications that need secrecy. Why? Because: * It's default-plaintext. We don't generally love the way websites ensure they're viewed securely, but email doesn't even have the basic mechanisms HTTP has to p…

Not sure why anyone doubts or is upset by this. In my field, health professionals send all sorts of critical confidential information in email, and never delete any of it. For each person where email has good enough security, or can be made as such, there are 10 where it will never be remotely adequate in real world usage.

Re: Convenient End-To-End Encryption for E-Mail

#108

Post by rdslw » Sun, Jan 07, 2018, 10:02 AM UTC

tptacek wrote: post #8

Unpopular but very probably true fact: email can't practicably be made secure, and people should stop trying. Email is itself archaic, and there aren't good reasons people should use it for routine peer-to-peer communications that need secrecy. Why? Because: * It's default-plaintext. We don't generally love the way websites ensure they're viewed securely, but email doesn't even have the basic mechanisms HTTP has to p…

IM won't replace e-mail due to two important things you seem to be neglecting (for a long time :) ). They are:

* human psychology and ways of working

* lack of features on IM (and this problem is bigger than implementing crypto in e-mail).

_

Let me describe them more, starting with humans:

* we love to separate things in our minds, like work/home linkedin/facebook profiles that will never merge, no matter how much money fb will pour into fbworks or others.

* we assign e-mail, an aspect of 'longer asynchronous communication'. We desire this 'asynchronous' aspect, allowing replying us with a delay. We demand that a separate (sic!) tool with such characteristic (and publicly agreed typical use) exists

* we need communication tool for longer (like this or yours post) exchanges, where MULTIPLE people can participate. We need to able to put into one message 10..20 minutes of work. And no, we will not be publishing and exchaning academic papers (read attachments/separate documents) for such discussion to happen.

* it can't be tied to instant/short comm tool.

_______

Features:

* we need (must) to have a searchable archive of this communication tool, instantly available, surviving device changes (telegram and signal are out), and multiple years to store

* this tool must be connected to publicly available namescheme of internet: domain names - no IM are, they create they own space. This is ultra crucial: I must be able to send and receive information to a participant who I know only a domain. Like for examples yours: youagain@latacora.com

* I need to be able to talk with multiple people, knowing who they are (domains), and @Immuppet1980 or @894984320123 is not, while tptacek@latacora.com is

* we need to to have multiple addresses all being accessed with relatively small number of clients (read 2). Welcome to the IM hell, when if you're 40 and have friends from around world you need to ahve: signal, telegram, fb, whatsap, sms, ghangout, alo, and I'm not even started with asian tools! This sucks.

_

So no, while I share your despise to current crypto-email state, the proper way is to try to secure e-mail, not to get rid of it. Incrementally, getting rid, one by one all bad things of it. There is no bing bang approach.

Re: Convenient End-To-End Encryption for E-Mail

#109

Post by ebcode » Sun, Jan 07, 2018, 10:12 AM UTC

a3_nm wrote: post #105

tptacek wrote: post #27

Earlier quoted context omitted.

You seem to be relishing this takedown post. I don't want to harsh on that, since I enjoy writing a takedown as much as anyone, but I have to point out that you're attacking an argument I didn't make. It's not my argument that people should use special secure messaging applications when they need security, and email at other times. It's that we should stop using email pretty much altogether. Like I said: it's archaic…

> a lot of us look at our email inboxes these days and notice that most of what's in there is automated transactional stuff, with occasional cold inbound introductions that quickly transition off into some better medium Just wanted to point out: that's certainly not true for everyone. The overwhelming majority of my work communication is done by email, and an important part of my social communication with friends and…

>Is there another communication system that is decentralized (...), and is also widely used?

XMPP, maybe?

Re: Convenient End-To-End Encryption for E-Mail

#110

Post by guy98238710 » Sun, Jan 07, 2018, 10:56 AM UTC

brongondwana wrote: post #85

jopsen wrote: post #77

Earlier quoted context omitted.

Indeed just getting most senders and servers to use TLS would be a good start. That said, lots of businesses deal with sophisticated attackers who are trying to steal trade secrets, patents in progress, etc. Sometimes these attackers are state sponsored too (I would definitely suspect China, US and Russia for this kind of crimes).

That comes down to risk analysis there. These businesses should probably be running their own mail infrastructure and doing exfiltration scanning of all outbound messages (which needs them to be in the clear at that point, or at least decryptable by the gateway box). Those sorts of businesses also benefit massively from being able to scan incoming messages for spear phishing and viruses BEFORE they get delivered to t…

You assume that secrets circulate only within organizations and that no external parties (contractors, business partners, investors) are involved.

Outbound filters aren't smart enough to detect escaping secrets. And inbound malware scanner can just as well run on the target device or it can be invoked from the device for suspicious attachments.