Hacker News Reader

The problem with arguments by security experts is that they ignore the reality of ergonomics and convenience. If you're in security and you ignore these, you're being naive and likely making dangerous recommendations.

Why do I make this claim? Because if you were realistic, you'd acknowledge that people will inevitably choose the easy route over the secure route. The path to genuine improvements to common place security has to include a focus on methods that are ergonomic and convenient.

Just look at the outdated password complexity rules as a perfect example of this. Sure, in some ideal world where everyone did the hard thing this would be secure. In reality these rules just drove people to write their passwords down on sticky notes under their keyboard.

Signal in the current form is not and will never be a replacement for email due to UX. It's a great messaging platform, but it doesn't solve the use cases that email does.

I encrypted email were the "easy" route you'd be right, but obviously, it is not. It has vanishingly small usage and is notoriously unusable (see: several generations of "Why Johnny Can't Encrypt" papers).

If email served the same purpose as messaging, if the messaging apps were as capable as email, this also wouldn’t be an issue. Email is the “easy” route to encryption because there are no alternatives.

If there was some kind of magical answer to the problem of the network effect, we wouldn't be in this mess with say privacy disregarding Facebook.

All this article is doing is explaining how encrypted email is akin to snake oil, and how we can break the network effect of email (by not recommending it for serious comms).

> There's simply no case that can be made that encrypted email is as secure as a modern secure messenger.

-- BEGIN SCRATCH THIS

Of course there is. I can send an encrypted email to anyone and be guaranteed that only that person has access to it, even if I have to give them instructions on how to decrypt it.

I can't do that with Whatsapp because it's closed source. I can't do that with Signal because nobody has Signal. Everyone has email.

-- END SCRATCH THIS

There's also the problem that messengers like Whatsapp and Signal are tied to my phone and so to my identity. With email I can make a free, new email account with almost any provider and send an anonymous, encrypted email from a public Wifi with a spoofed MAC.

You can't get that level of anonymity that easily from using a phone. Every phone provider I know will at least want to keep a record of your ID before giving you a new SIM card.

EDIT: I concede my first argument sucked.

> I can't do that with Whatsapp because it's closed source. I can't do that with Signal because nobody has Signal. Everyone has email.

Are you saying the install base for people who use GPG with e-mail is larger than the user base for Signal, or are you saying you can send people instructions for decrypting e-mail but for some reason not instructions for installing Signal?

You know what. I'll accept that it's not that good of an argument and scratch it, leaving the other.

> I can send an encrypted email to anyone and be guaranteed that only that person has access to it, even if I have to give them instructions on how to decrypt it.

Genuine question: how would you send me an encrypted email, and give me instructions for how to decrypt it? I have no published public keys; you'd have to send me a keypair that you yourself generated - how would you do that part securely?

I can also send you the commands to copy-paste into your terminal to generate the key pair and ask you to give me the public key.

That could def. be MITM’d though

That would have to be someone actively engaging in MitM and not merely listening and keeping record.

Even if that's the case though, you can raise the difficulty by doing it through a phone call.

You could associate your public key with a DNS record that you control?

e.g. https://tools.ietf.org/html/rfc7929

The MitM problem is not with sending the public key. They can just email it. The MitM problem is with intercepting the instructions from person A, having the MitM person generate them, and provide the pair to person B while impersonating A.

If you know you want to email alice@example.dk and if you trust DNSSEC, then fetching the public key for alice@example.dk from the DNS should be at least as secure as visiting https://example.dk in your browser.

(If you don't trust that Alice's email address is alice@example.dk then you shouldn't send an email for her to that address regardless of MitM attacks.)

You're omitting the part that example.dk could create a fake key for alice@example.dk, publish that, decrypt a copy for themselves, and reencrypt it for alice@example.dk's public key.

Well, I said it's at least as secure as visiting https://example.dk in your browser, where your attack is equivalent to the hosting company or DNS provider generating a new TLS certificate for that domain without the knowledge of Alice, the nominal registrant. (The web PKI also has the problem that any CA can issue a certificate for any domain).

The catch is that the primary reason to choose encrypted email is to prevent your hosting email provider from reading your email, so the inability of encrypted email to provide that guarantee kind of renders it worthless.

Of all the attackers you could worry about, I wouldn't put your own email hosting provider at the top of the list. MTA-STS is nice, but it's hard for an email client to guarantee that the hop-to-hop links between itself and the recipient's inbox are going to be protected with TLS. Passive snoops between mail providers seem like a much more realistic threat.

Also, by putting a public key in the public DNS, it means that Alice can catch her mail provider's DNS server giving false information about her public key, which would come with cryptographically signed proof of which entities were involved in that lie. Ideally there would be an equivalent to the Certificate Transparency system for keys that are used or protected by DNSSEC.

> ... and if you trust DNSSEC...

I don't, thanks.

This is orders of magnitude more difficult than just telling someone to install Signal. Even people who are somewhat tech savvy are going to have trouble with these instructions. I freely admit that I have no idea how to do what you're proposing I do.

The way this happens today in the real world is that I send you an email with an encrypted zip file attachment (and I make sure I've chose an appropriately secure encryption method) then I call you (or meet you in person) and tell you the password.

Symmetric encryption has ergonomics which are actually easier than asymmetric encryption with the tools we have today.

Isn't authentication just as important as encryption for secure communication?

What is the benefit of being both anonymous and encrypted?

You can do authentication with the party you're communicating with as your real identity or as a pseudo-identity without letting everyone else know who you really are.

With PGP, just use an identity that identifies you to that party and sign your emails with it. It doesn't matter what address you send them from.

However, anonymous emails where you don't even authenticate yourself to the party your communicating with is also useful. It's like when someone wants to make an anonymous report to the police. Why leave a trace with the phone company? I imagine people that make these reports typically use street phones (in countries where they're still plenty).

Instead of instructions for how to use PGP to you could give instructions on how to use Signal.

A new SIM card isn't free, but it seems like it would be easier to reliably cover your tracks by buying a burner phone with cash than concealing your PII through the process of setting up a new email account.

That's at least the case in the USA; I don't know if you live in a country where it's more difficult to anonymously obtain a new SIM card.

>I don't know if you live in a country where it's more difficult to anonymously obtain a new SIM card.

ie. most countries.

I wasn't aware. Do you have some specific examples, for my own edification?

This page seems to track them. The linked paper has some nice maps

https://privacyinternational.org/long-read/3018/timeline-sim...

That's a great link! Thank you, very much

Ecuador us one such country.

So use a secure messenger that isn't tied to your phone. Wire is an example. I'd strongly prefer Signal, because the reason Signal is tied to your phone is so they can piggyback on your contacts database and not keep a plaintext contact graph serverside where it's vulnerable to interdiction. But Wire is still vastly better than encrypted email.

using the contacts feature of the phone, in most cases means the contact graph is shared/synced with google, apple servers. It's great Signal does not need a copy, but by outsourcing the contacts they have already leaked and its just pretending to solve the problem.

This is all true, but it's still a real problem that a secure messaging service with the ergonomics of email doesn't exist at the moment. No, I'm not going to use Signal instead; I mean, I do use Signal, but it has the ergonomics of text messaging, not email. I don't use it as an email replacement. So, uh, somebody please build one I guess? :-/

> The problem here is that there are real people who depend on the security of their messages who would be taking unreasonable risks in trying to get an encrypted email workflow going.

But how do you decide who is taking unreasonable risks?

Surely there are also some people who would be taking unreasonable risks communicating via any means other than a one-time pad exchanged in person!

And yet I suspect most security professionals will say that in most use cases the ergonomic disadvantages of one-time pad make it not worth the added security. Which is the exact same form of argument you said is problematic regarding secure messaging services.

Cryptography engineers virtually never use one-time pads, because the ergonomics are impossible and the security benefits over a modern (as in, past the 1970s) cipher are marginal. Ironically, similar to encrypted email, a reason not to attempt one-time pads is that you will inevitably screw them up (and there is, like with PGP, a history of operational screwups to point to here).

If your point is that the risk calculation isn't literally binary, that's true. But it's pretty close to discrete.

Is encrypted email sufficient for the LARPing use cases that almost all encrypted emails represent? Sure. But when we discuss secure messaging as a generality, we have to consider the cases where security actually matters, and in those cases encrypted email is not fit for purpose.

How is email cryptographically inferior? Only thing I can think of is if you want perfect forward secrecy, you can segment and deliver parts of the email with different encryption keys (except you could if you have it and send each blob in a thread).

That just depends what encryption protocol you use.

You could say that the user experience around encryption in email is inferior. Is that what you mean?

The answer to your question is in (in fact, is) the article.

I think you could still hack around it, but in a way that would make non-secure emails come across as gibberish to those that weren't using a special email client.

For subject line, locally you could encrypt it via the same key that you encrypt the message body, so that it would look like gibberish until the end client decrypted it.

For send time, nothing you can do there. If you wanted to hide the sender address, you could likewise obfuscate that by proxying based on a secret key, but at that point you need a custom email server.

I guess I'm thinking that it would be useful to have an email client can:

  - do it's own custom security thing (probably not even on SMTP protocol) if the receiver is also using secure mail
  - send a normal email if the receiver is not using secure mail

At that point, I'd guess you probably wouldn't call it "secure email" though :)

Okay, so what blend of secure messenger is your friend-group using? I am hoping Signal becomes more mainstream but it isn't nearly the population that uses GPG for email..

(I do agree with you)

Everyone I talk to uses Signal; even my siblings, who are not technologists and who I do not talk to about this stuff, use Signal (sometimes to my annoyance, since iMessage works just fine when we're figuring out what each of us is bringing to dinner). But for the purposes of this post, almost literally any secure messenger is better than email.

Do they use Signal of their own accord, or because you asked them to and they were receptive to using it? Do they use it when talking to other people that aren't you?

It is not because I asked them to. I'm the one telling them to go ahead and use iMessage.

I'm more talking about how they initially chose to use Signal. Did you tell them about it, or did they learn about it on their own? Do they prefer it because of its encryption or security features, or for other reasons?

I did not tell them about it. Signal has received a lot of press coverage. They use it because it's what they think they're supposed to use.

Do I read you correctly that you are actually admitting that there might actually be room for more than one type of messaging?

Try tapping that mr NSA! :) 1st word over whatsapp, 2nd word over telegram, 3rd over signal, and so on. Each word of course PGP encrypted ;)

I wonder if you're in a bubble. Only 3 people I know use Signal, and it was a hassle getting one of them to start using it. Most people are still happy with SMS or Facebook (or probably iMessage, but as someone who avoids Apple, that's not an option for me).

I switched over to Keybase from Signal about a year ago. I avoid SMS, iMessage, and email as much as possible. I've had no regrets, and almost zero downsides. The cross-platform support was the biggest driver for me, along with other bonus features.

Many people in the circles I run in have adopted it recently.

Here's what it boils down to.

I don't trust you.

My threat model is what happens when the CIA plants child porn on Joe Average Developer's laptop and he gets a plea deal.

For RFC4880 the answer is "one implementation of the standard is compromised".

For Signal, Wire, Whatsapp and everyone else that provides an end to end solution the answer is "everyone in the world is fucked".