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.
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).
-- 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.
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?
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?
Symmetric encryption has ergonomics which are actually easier than asymmetric encryption with the tools we have today.
(If you don't trust that Alice's email address is [email protected] then you shouldn't send an email for her to that address regardless of MitM attacks.)
I don't, thanks.
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.
Even if that's the case though, you can raise the difficulty by doing it through a phone call.
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.
ie. most countries.
https://privacyinternational.org/long-read/3018/timeline-sim...
What is the benefit of being both anonymous and encrypted?
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).
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.
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.
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?
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
(I do agree with you)
Many people in the circles I run in have adopted it recently.
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".
The problem with these arguments is that they have nothing to do with security. There's simply no case that can be made that encrypted email is as secure as a modern secure messenger. People tolerate shoddy encryption in email because ergonomics are more important to them than security.
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. Rather than telling these people to read a GPG tutorial or install Enigmail or whatever, we should be telling them either to use a secure messenger, or not to put themselves at risk at all.