Comment by Sniffnoy | Hacker News Reader

Comment by Sniffnoy | Hacker News Reader

Parent Full thread

I'm going to say the same thing I said last time this came up -- so what should we use instead, then? What do we use if we want secure messaging, but with the (social) affordances of email? There still doesn't seem to be any answer to that!

No, Signal is not an acceptable answer; it replicates text messaging, not email. In more detail:

1. Email is potentially long-form. I sit down and type it from my computer. Text-messaging is always short, although possibly it's a series of short messages. A series of short emails, by contrast, is an annoyance; it's something you try to avoid sending (even though you inevitably do when it turns out you got something wrong). Similarly, you don't typically hold rapid-fire conversations over email.

2. On that point, email says, you don't need to read this immediately. I expect a text message will be probably be read in a few minutes, and probably replied to later that day (if there's no particular urgency). I expect an email will be probably read in a few hours, and probably replied to in a few days (if there's no particular urgency).

3. It's OK to cold-email people. To text someone you need their phone number; it's for people you know. By contrast, email addresses are things that people frequently make public specifically so that strangers can contact them.

So what am I supposed to do for secure messaging that replicates that? The best answer I've gotten for this so far -- other than PGP which is apparently bad -- is "install Signal on your computer in addition to your phone and just use it as if it's email". That's... not really a satisfactory answer. Like, I expect a multi-page Signal message talking about everything I've been up to for the past month to annoy its recipient, who is likely reading it on their phone, not their computer. And I can't send someone a Signal message about a paper they wrote that I have some comments on, not unless they're going to put their fricking phone number on their website.

So what do I do here? The secure email replacement just doesn't seem to be here yet.

(I'm guessing in case (3), the authors would suggest just using unencrypted email, but what about problems (1) and (2)?)

I was going to write the same thing, but less eloquently!

The solution seems simple. Create something much like signal, but with the user-interface of e-mail! This addresses your points 1 and 2 perfectly. I'd want my UI to include actual working archives. None of this 'this message will be deleted automatically after x days'. Because e-mail is non-ephemeral communication. Hence I want to be able to access it.

However, point 3 introduces a relevant technical difference between signal and e-mail that affects the user experience.

Federation.

This is what makes cold e-mailing possible. It is what allows anyone who controls a domain to start accepting e-mails at that domain without needing permission, or any central service.

I don't have enough of the infrastructure of signal's ephemeral key pre-sharing front of mind. But I really hope there is some way to get this to work in a federated system. I could eventually see this replacing e-mail.

Point 3 has one more side-effect that hurts any e2e encrypted form of communication: spam-filtering. Because content-based spam filtering essentially requires access to the plain text. And for it to be effective, you want to base your filtering on a large dataset. Even if you were to move applying the spam filter to the endpoints (ignoring compute and trade-secret issues), you still need access to plain-texts to train your spam-filter.

Sure, you could probably share any false negatives back to some aggregator to train the spam filter. Because generally spam sent to you doesn't need to remain confidential. However, false-positives i.e. emails that are wrongfully marked as spam, are not things you'd want to share back to some aggregator. I suppose MPC could be of help here, but that would 1) fix the algorithm used and 2) have huge computational overhead.

In summary, if we can federate e2e encryption and get spam-filtering to work, we could and should replace the entire user experience of e-mail with an e2e encrypted protocol.

> I don't have enough of the infrastructure of signal's ephemeral key pre-sharing front of mind. But I really hope there is some way to get this to work in a federated system.

Well, there's one major hurdle: multiple devices. Pre shared keys (and one time keys, and ratchet keys) are generated on the user's computer. If there's several of them, say a Wintel desktop and an Android palmtop, messages sent with the desktop's pre-shared keys can't be decrypted by the palmtop¹.

So we need a need to synchronise those keys between the devices. The easiest way to do it is to store the private half on the recipient's server. But then you need to encrypt them to prevent the server from breaking forward secrecy. The encryption key must then be shared across both desktop and palmtop. (UI wise, it's pretty easy: connect both devices to the server, then manually type on the new device some low-ish entropy secret the old device is displaying on screen.)

[1] Commonly misnamed "phone"

In theory, both Matrix and XMPP+OMEMO handle multiple devices. In practice, I've found it to be less than smooth.

Matrix has gotten much better about this. Most scenarios where device lists get out of date are caused by the device list cache for federared homeservers being out of date. But with synapse 1.10 (released a few weeks ago), homeservers will refresh the device list much more aggressively in circumstances where it's clear that the cache is old (such as receiving a new message from a federated user on an unknown device).

If what you really need is security, then I don't see how (1) and (2) can be overriding concerns. If I were in a situation where my life depended on my messages being confidential, my choice of medium wouldn't turn on the convenience of long-form messages or social conventions around reply time.

To put it another way: if I'm in a situation where being able to type an easy-to-read long-form message is more important than it being end-to-end encrypted, I'd just use Gmail. I don't see why Signal needs to satisfy both use cases; at worst it's kind of ergonomically awkward, but it isn't making false promises of security, which is worse than useless.

Oh hey Mickey :)

Obviously, if what I really need is security, these aren't overriding concerns! But I think part of the point is that you should be using these things even when you don't need security -- otherwise when you do use it, it's potentially suspicious. Secure messaging needs to be ordinary, not something special you only do when you need security. Signal accomplishes that well for text messaging! Nothing, apparently, really accomplishes that well for email while also being seriously secure.

Edit: Or to put it another way -- tptacek talks about people "LARPing" by using attempts-at-secure-messaging when they have no need for security. But, such "LARPing" is actually important, as it creates cover for those who do need it! Just, y'know, we still need the actually-secure part.

Yeah, to me, this is the most important response.

In theory, you could layer an email UI over a federated secure messaging protocol, like Matrix's E2E or XMPP+OMEMO. In practice, no one has done this, and infosec people only seem to care about instant messaging for some reason.

Besides all of the points you make above, Signal Desktop is terrible. I often want to use it to avoid typing on a phone keyboard, only to find that the experience of using Signal Desktop is actually worse than that of typing on my phone.

Reply on news.ycombinator.com