I understand that sending email in plaintext is a design issue for email. And that PGP is outdated.
However, I think it’s possible to have a system completely in the open and still be secure. Bitcoin comes to mind. I don’t think the problem is with email, but with the lax encryption models and the lack of support by email clients and servers alike. Wouldn’t you agree?
"Completely open" is not the only useful property to discuss about a system. Email itself is still fundamentally terrible for secure messaging.
Your argument seems to boil down to: "bitcoin is open", "bitcoin can $X", "email is like bitcoin", therefore "email can $X". There are a few flaws in that argument. Firstly, Bitcoin is pseudonymous, it makes no attempt to hide transaction details, which obviously message security would need. Secondly, even if the properties of bitcoin were relevant to messaging, at best you've made the argument that "a system with public transaction records can still do what you need for safe messaging", but not "email specifically can do what you need".
There are two ways I could see your argument working out and both are pathological examples. We can do secure comms over TCP, so just design a secure comms system and then all the way at the end choose a blockchain or email as your transport. That sounds true, but also doesn't seem like a useful thought tool that results in improving anyone's communication security tomorrow.
I'm not sure why you feel like calling my arguments pathological, or a false equivalence. I'll disregard this.
I did not introduce any equivalence about valuation in my argument. I used Bitcoin as an example of a well known open database, where everyone can see the data (arguably an analog to plaintext exchanges) and yet it's secure.
Additionally, your point about Bitcoin being pseudonymous also applies to email. You may create your own address, on any number of servers. At a high level, it feels like the pseudonimity is essentially the same.
Are you proposing people stop using email and switch to a more secure messaging system, like Signal? Or maybe to make an email app on top of tech similar to Signal (kind of like Protomail?), or to improve email by baking in modern security standards?
I did not call your arguments pathological, I called my own examples pathological to clarify that I am not trying to strawman you: I appreciate that my own examples are almost certainly not what people have in mind when they talk about email security.
The pseudonymity is precisely one of the reasons e-mail does not work well. One of the features of secure messaging as it is commonly understood is participant privacy: hiding who participates and ideally when. This is the metadata leakage problem described in the post.
You're restating your argument of "bitcoin is public and yet it is secure and so it is possible to have secure systems that are public". I understand that, but you don't appear to have engaged with my counterargument: "secure" is not a universal term, and things that are fine bitcoin transactions are not necessarily fine for secure messaging.
Protonmail does not seem like "tech similar to Signal" to me at all. I'm all for implementing stuff like MTA-STS, and I appreciate e-mail isn't going to die any time soon. I think that trying to add E2E-style encryption to e-mail is fundamentally doomed, signing for e-mail is mostly doomed, and yes, private conversations belong on something like Signal.
It’s interesting that you feel email has a lot of traction and is broken, but you see that as an argument for moving away from it. I would think it’s an opportunity to fix that system, since users are unlikely to switch. I’ve thought quite a bit about what making email like Signal would look like, but I’m curious what’s your take on the overall problem.
I do not think it is meaningfully possible to fix that system (I say meaningfully, because I'm excepting the pathological senses I mentioned above). If you want it to look, feel like email and be compatible, you can't secure it.
MTA-STS works because it does not require end users to do anything. If you need end users to change their workflow, you could try to do that with e-mail (which fundamentally can't do all the things you need it, per the post and the PGP post), or you can just make them use a non-broken protocol.
I guess I don’t understand why you would think that the following wouldn’t work:
- use random email addresses
- encrypt the content with something more secure than PGP (on the client)
- receive the email and decrypt it (on the client)
Sure, it’s plaintext, but I don’t see the downside?
How do I securely communicate what the new email address is? How do I hide IP-level metadata? How do I hide time-level metadata? How do I do PFS?
At some point you're going to keep adding lipstick to the pig until eventually you have something morally equivalent to the pathological example I gave.
The security flaws with email are completely fundamental. It is not possible to "fix" email without disrupting the existing users. If you're forced to disrupt existing users, then you might as well switch to a more securely designed protocol.
Okay, so what would a secure email alternative look like?
Can we design a system such that sending a message from alice@foo.com to bob@bar.com is reasonably secure and private? How does Signal/NOISE solve this? Why can those not be applied to non-messaging systems (or, at least more traditionally structured messaging systems - which is itself a questionable definition since email threads are a hack, its mostly just independent blobs)?
I guess I'm off to read the whitepapers for NOISE and Signal tonight to see how the models differs.
This is an instance where I'm perfectly happy to talk up Matrix! People would be a lot better off using Matrix than they would be trying to encrypt emails.
This is potentially the most interesting subthread on this otherwise well trod discussion. Some large entities (German Govt., Mozilla) have announced moves to Matrix. I'm curious as to whether there is anything inherent in the protocol that makes it more efficient for longer-form conversations than Signal (Matrix is also supposed to be for IM after all).
I would love to see a protocol added, so that when alice composes an email a request is sent to bob@bar.com with a special header to retrieve bob's private key. This in turn would be signed with a cert from bar.com, which in turn is signed by one of the same trusted CA's used for HTTPS traffic.
Is there anything like this currently implemented / standardized?
There's something crappy-ish and similar for email with DKIM. That doesn't sound the same, because it's the server signing, not the sender -- but in this protocol you're kinda already trusting the server anyway. The critical difference is that DKIM is not protected with WebPKI.
ActivityPub will bootstrap public keys from WebFinger (over TLS/HTTPS).
Keybase has an even more complicated key escrow-based system (that works for any of their "Proof" types, not just domain ownership) if you trust their clients, where your client generates an ad hoc key for the recipient and essentially a "for bob's ears only" claim and on verifiable Proof from Bob securely exchanges the ad hoc key to Bob's new public key. Which is interesting because it allows for people that haven't yet setup keys to eventually receive them so long as you trust Keybase's clients and their Proof infrastructure.
Agree with pretty much everything in the article. Encryption is not a property of email, and will never be. And if you manage to add a perfect encryption solution on top, it stops being email.
The most that can be done at this point is to build a new closed "email v2" which cannot interoperate with any existing client out there, but because of that it will inevitably be dead at launch.
Something like that will eventually happen, because lots of people want a good desktop mail-like experience for secure messaging. And there's nothing wrong with that, as long as the backplane for such a system isn't SMTP email.
It's not the core email UX that's the problem; it's SMTP email that's the problem.
Would such a desktop client have to disable copy-to-the-clipboard, because otherwise you won't be able to stop bozos from copy-and-pasting from this new system into an MS Outlook all-company email?
What I mean is, doesn't the ubiquitous presence of ordinary email on the desktop create an unacceptable risk of the "inevitable unencrypted reply" for any secure messenger on the desktop?
Top practitioners like Zimmerman himself famously replied unencryptedly to encrypted messages. Copy pasting something in a different program seems hard to do by accident. But sure, let’s stipulate we break copy paste :)
It's not the core email UX that's the problem; it's SMTP email that's the problem.
You're article seems to argue the opposite to me. For example, the following quotes are all related to the email UX:
1. In any group of people exchanging encrypted emails, someone will eventually manage to reply in plaintext, usually with a quoted copy of the entire chain of email attached.
2. Every archived message will eventually leak.
My understanding is that it would be possible to create an alternative app that is compatible with the Signal protocol that would provide a different UX. This alternative UX could, for example, offer the ability to save all messages onto google docs, eliminating the benefits of secure messaging.
There is nothing about the core UX of email that requires plaintext as an option; you can straightforwardly imagine, and probably even readily implement, a secure messenger with the same UX as Outlook in which it's not possible to plaintext-reply a message, or send plaintext at all.
Archival is a problem. But you can also imagine something with the UX of Outlook that implements the same advisory-level disappearing messenger feature that modern secure messengers have; in fact, I wouldn't be surprised if you told me Outlook already has that feature (but that it only works for Outlook users).
The problem is the legacy of SMTP. It's not what the UI looks like.
That feature isn't trying to prevent people from deliberately archiving or forwarding messages in a way that the sender didn't intend, expect, or prefer.
Sure! But a screenshot is trivial to forge anyway, and even if you block PrScrn, people can always taddle. The goal is to get the message safely to the recipient, not prevent the recipient from disclosing anything afterwards. (Non-repudiation is a common goal, but screenshots being easy to forge solves that.)
I don't think you've addressed my point. My point is that an alternative client (and hence UX) for the Signal protocol could still have all the flaws that you point out about email. Therefore, the security of Signal is fundamentally dependent on the client/UX. A bad client (that is 100% interoperable with existing the existing Signal client) would break Signal in the same way that email is broken.
Of course such a client for Signal doesn't exist and is unlikely to become widespread even if it were created. Therefore Signal is more secure. I agree with your conclusion and everything in the article; I disagree only with the claim that it is not a UX problem, and the disagreement is likely that we are drawing the boundaries around what constitutes UX in different places.
No, it could not have all the flaws that I've pointed out. It seems pretty obvious to me why an alternate Signal client wouldn't have those flaws. Be specific about which one you're thinking of.
An alternative signal client could forward all messages to a gmail account (pt 1 from my original post) and store the messages in plain text on the local computer (point 2).
Of course these would be very poor design choices for the alternative client, but none-the-less technically possible.
This is not the point of the commenter you're going back and forth with on the thread, but as I read this it occurs to me that some version of the plaintext reply problem exists in real life regardless of protocol.
That is, once the recipient has plaintext, we don't know what they're going to do with it. They could read it aloud in a crowded place. They could blab about it to all their friends. They could pass it verbatim to somebody else. Or more innocuously, they could store it in an insecure database as in this commenter's scenario.
Now, if you're using something better than email, the protocol itself won't be the problem and it's less likely (or impossible through the protocol itself) to be an unintentional plaintext transmission, so this fact is pretty moot and not at all a justification of how email clients might behave. Nobody building these systems has to necessarily be concerned about protecting against "social" types of plaintext leaks.
This is what people are talking about when they talk about the "Print Screen" button or screenshots or securing the clipboard. But I'm not kidding about the "inevitable plaintext reply" problem. Everyone I know who has used PGP at scale has seen it. These aren't people deliberately doing dumb things; they're doing things a bad tool begs them to do, because the underlying system is designed for, expects, begs for plaintext.
Nobody can do anything about people deliberately subverting the security of their privacy tools. There's nothing deliberate about plaintext replies. The people who do that don't want their messages sent in plaintext.
I agree they are not interesting points. But they are exactly the problem you are complaining about for email.
Also respectfully: If the point of your writeup is to suggest that the signal protocol is better than the SMTP protocol, then I suggest you delete those points from your writeup. If the point of the writeup is that the signal experience is better than the email experience, then I suggest you stop claiming that the signal protocol is better than the SMTP protocol.
Am I missing something? I thought the PGP vulnerability wasn't in the Cryptography but the mail client rendering the HTML like a browser and allowing it to be outgoing. Still a dumb move but fixable via going plain text everything.
Granted the metadata and backlog issuss are themselves serious issues for the format.
It is more a "stop using email even if encrypted" than "stop encrypting email".
I think the overall advice is "stop using email for stuff you expect to be E2E encrypted". There are still valid use cases for "regular" email, and I'm okay with most of it hosted on Gmail and searchable etc.
A point you can make here that really upsets technologists is that organizations with real practical security concerns (for instance: most technology startups) can and do use the email infrastructure to have conversations that involve secrets --- but (1) almost none of them use encrypted email and (2) they rely heavily on GSuite for their security. And, for business-level secrets, this is usually fine! Better (more secure!) in fact, than the outcomes they'd get from trying to make the same workflow work with encrypted email! I feel like there is a kind of technologist whose head explodes when you tell them that links to GSuite documents are a safer workflow than PGP, but that is sometimes the case!
This, of course, goes out the window when your threat model is extrajudicial.
Agreed, although change GSuite to Outlook. E2E encrypted email would be considered a security risk at every company I know, and in fact would be illegal in a lot of sectors. They want to use IRM etc. for encryption and access management but also want complete control of the keys.
There's not "one" PGP vuln: one of the things that makes PGP so pernicious is that it's a spec, a de facto implementation (GPG), an ecosystem used in different contexts (e.g. enterprise file transfer, but also e-mail) by completely different user archetypes. But yes, this post focuses on problems with email in general and why the problems are deeper than something solved with a "better PGP".
> one of the things that makes PGP so pernicious is that it's a spec, a de facto implementation, an ecosystem used in different contexts (e.g. enterprise file transfer, but also e-mail)
Just like SSL/TLS and SSH? They're both specs via RFCs, they both have de facto implementations (openssl and openssh), and they're both used in different contexts (ssh can be used for file transfers, besides remote shells; TLS's applications are very broad like PGP's).
Great point! Sorry, I should have been clearer: the pernicious part is in _explaining how PGP and encrypted is bad_, which is a Herculean task because there's always another little use case broken in its own subtle way. TLS and SSH have that problem far less, because where they have issues (e.g. SSLv3, let's say), the issues are singular (e.g. the problem is that the obvious way to implement this introduces a padding oracle), not like GPG, where the issues are fractal (e.g. this isn't a real authenticator and consumers can be tricked in unauthenticated data -- a problem that requires a constellation of both GPG's broken crypto but also the specific context of e-mail and also a vulnerable client).
This claim about Efail is essentially false. Efail was possible because PGP uses an archaic message authentication scheme, one designed more or less before the dawn of authenticated encryption, which can be stripped off messages, and which is in a real sense an "add-on" as far as the core of PGP is concerned. PGP will release unauthenticated plaintext to its callers and count on them to check out-of-band errors to see that the plaintext isn't safe; mailers failed to reliably perform this check.
There is a technical sense in which mailers are responsible for mitigating this vulnerability, but it's a vulnerability that can't exist in the first place in a well-designed cryptosystem.
In the context of this post, this is basically a nit; the point the post makes is that even if you replace PGP with something like Age, encrypted email is still too risky to use, and is intrinsically inferior to modern secure messengers. (Encrypted email is not a use case Age is pursuing, and I do like Age).
My only annotation here is that I think MDC was added in the early 2000s, after HMAC. My understanding is it's not so much that we hadn't figured out real authenticators, it's that the people designing PGP didn't believe in them or believed them unnecessary for some reason. You can see the echoes of this silliness in the description of MDCs in the RFC today, because of course RFCs are for pontification and not for spec description. (Grep RFC4880 for "NON-NORMATIVE EXPLANATION" if you're interested.)
It is not, no. The problem we're talking about allows you to exfiltrate plaintext from messages you don't have the keys for, which you can do because PGP makes the ciphertext of messages malleable. This Age discussion pertains to entire messages that attackers construct from scratch under their own keys.
Claiming that EFAIL somehow showed a weakness on the part of PGP and S/MIME is like saying that a caretaker that lets burglars into their tenant's apartment is an example of bad lock design. Sure the lock maker could of removed the ability to use a master key but that is simply not a reasonable thing to suggest.
I can't follow this analogy. Claiming that Efail showed weakness on the part of PGP is like claiming that cryptosystems should be designed not to release unauthenticated plaintext to callers, and that the "authenticated/unauthenticated" status of a message shouldn't be communicated out of band. You know, like how all modern AEAD cryptography works.
Sort of just generally, to word this post more simply: whenever the point is made that encrypted email is cryptographically inferior to secure messengers, people respond with a litany of ergonomic reasons why secure messengers aren't viable: they don't have the right platform support, nobody wants to type on their phones, people want decentralized platforms, nobody wants to install new software, and on and on.
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.
> 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.
> 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?
> 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?
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.
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.
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.
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.
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..
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?
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 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.
> 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?
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 :)
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).
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? :-/
LARP here is a link to Google and from the results I can only assume that it expands to "Live Action Role-Playing (Game)". I don't get how that's related. What is "Live Action Role-Playing Security"?
Role-playing someone who needs to and does send encrypted messages, was how I read it. As in, make-believe security for fun, to feel more like a spy or something.
The author is presenting a binary view of email security.
It's true that email as a protocol has inherent insecurities ; and it's also true that dedicated, rich spies are probably able to exploit many of them even with encrypted message bodies.
But most of us are facing the problem of MASS SURVEILLANCE, which statistically is more serious.
So:
1. Stop using spied-upon email servers:
1.1 Drop your Gmail, Yahoo mail, Microsoft etc. mail accounts, in favor of non-US and/or non-huge-corporation mail service providers.
1.2 Try to get your friends and family to drop theirs. Yes, I know this is extremely hard...
1.3 Try to get your workplace / NGOs you volunteer in to drop use of those servers (and also of Google Apps, Office 365, Skype etc. which have strong tie-ins with the email services).
2. Use mail clients which auto-encrypt messages to recipients with known keys - like EnigMail for Thunderbird.
If you're going to do 1.2 and 1.3 and get everyone to make massive changes to how they operate, why not just use a secure messenger instead of trying to shoehorn privacy onto a protocol designed for when the Internet had like five computers on it and all the people knew each other?
Because email and secure messaging are not the same thing, and the latter does not replace the former. Now, there could be a distributed infrastructure for "email" that's not SMTP-and-IMAP/POP3-based, theoretically, based on what is now used for secure instant messaging - but I can't just recommend this to individuals.
Also, my suggestions do not make email private, they reduce the exposure to large-scale surveillance and make it more difficult to target individuals. Also, they do not involve "shoehorning" as far as user experience is concerned.
> But most of us are facing the problem of MASS SURVEILLANCE
All that you're accomplishing by switching to decentralized servers is publishing the metadata that you claim to be concerned about for free. Before, someone had to serve Google a valid subpoena to find out who you've been talking to. After, you're just broadcasting it publicly across the net in network header logs.
Yes, as far as I can tell you're claiming one of three things
1. Google actively assisted the NSA with data collection, beyond legal obligations (subpoenas etc.)
2. The NSA had a way of legally compelling companies to provide direct access to systems and can do arbitrary processing on company internal data
3. The NSA was snooping in Google's systems without Google's knowledge in 2013, and this hasn't been fixed 7 years later.
As far as I know, the Snowden leaks don't provide any real evidence for (1) or (2), and so are an extraordinary claim without evidence. (3) also seems rather unlikely. Hence the question.
But the outline of PRISM described there seems to confirm (1) and (2), no? They didn't need a subpoena for each user, had access to a search term firehose, and the legal method for (2) was the secret FISA court.
The access isn't as complete as full arbitrary data, but it's also a long way from only responding to known legal warrants and subpoenas.
If I encrypt a message and put the secret on an sd-card I hand to my friend at the park, I can mail him encrypted messages over plaintext e-mail and we are safe.
Most people don't use it this way, but to say it's impossible to secure e-mail is arrogant and not true
The metadata would indeed not be encrypted, how else would the message ever arrive? if the post-man could not make out the address or the sender or if the postage was valid -- it's the same issue.
This is a genuinely interesting problem which Signal put a bunch of work into solving!
Sealed Sender lets them arrange that your recipient knows you sent the message, but they (Signal and its servers) don't - https://signal.org/blog/sealed-sender/ is their blog post about this work.
Somebody connects to Signal, and hands over a message with a recipient. Signal has an ID for the recipient (you correctly observe there's no way around that) but has no idea who sent it, only that whoever it was can prove they're allowed to send this message. They also don't know in a useful sense who the recipient actually is - you can attach a real name, a photo and so on to a profile but only your trusted contacts can decrypt that profile anyway.
It also arranges that by default Sealed Sender only works for sending messages to contacts. If you're a spammer - sending unsolicited messages to people who don't know you - your only way to send messages involves disclosing who you are to Signal, who can choose to rate limit you or block you.
Like the rest of Signal's design the sender's identity is deniable - the recipient knows everything needed to produce a fake message from anyone they communicate with and so they can't use real messages as proof to anybody else.
Because I'm a nerd I actually have the status indicators described in that blog post switched on, so I know that a few weeks later, in the middle of chatting about RDR2 one of my friends suddenly began using Sealed Sender, and other participants in that group joined in over the next few days. To a normal user nothing changed, their privacy improved significantly without them noticing at all.
Anyway, solutions like PGP leak a lot more metadata than just the sender and recipient's identities to every node along the store-and-forward route.
And the very existence of the route also leaks data.
One of the concerns with email that article raised was: the recipient can click on "reply" -- without encrypting the reply message -- which would send the response together with the original message "quoted" - all of that unencrypted. This is apparently common operational mistake.
Note that this has nothing to do with key exchange, ie putting it on sd card or whatever, would not change anything about the issue raised above.
There is also about a dozen other issues that the article lists, worth reading for sure.
Oh yeah that's a huge flaw in implementation (that probably every main e-mail vendor is guilty of). If it's prevalent enough, then the article is warranted, but the title and the conclusion are still gross simplifications -- it's not like the piping is inherently flawed, it's just that we prefer clear viewing windows to interact with messages, and where these two trains cross is where privacy meets your eyeball and also meets oxygen. Really, all decryption should happen on-device; but we cannot afford to abandon indecipherable messages on a daily or hourly basis in favor of universal privacy. It's somewhat reminiscent of the LOSE_POINTS_TO_LAG flag in quake and setting it to false. Maybe a better title would be Encrypted Email quickly becomes Unencrypted
> So, for example, it recently turned out to be possible for eavesdroppers to decrypt messages without a key, simply by tampering with encrypted messages
When 'tptacek first heard of efail, we were both in the office, he called me over and said "if there was a disastrous GPG bug that fails in way $X, what would it look like" and my first answer was "of course it's that MDCs don't actually work and the packet stream is malleable and something is going to consume unauthenticated plaintext". That's not because I'm some sort of genius: it's because to anyone who has studied the protocol and has a cryptographic background, those flaws are glaring.
That matters because I think it's reasonable to blame a protocol when it is indisputably flawed (there is no debate about MDCs not being a MAC, there is no debate that authenticated encryption is important) and it turns out those flaws all but imply vulns.
It's just the old HTML email tracking image bug used to get out entire messages. Nothing really new or interesting past that. This is routinely exploited and is why those that are interested in privacy should avoid HTML mail.
Hey 'tptacek and 'lvh. You definitely make valid points. But your arguments here on HN could perhaps be reduced if you adequately framed the problem:
RFC 822/2822/5322 e-mail, on top of RFC 5321 SMTP and RFC 3501 IMAP, can't be secure. (And more RFCs I'm probably forgetting).
To most people in the target audience (LARPers, technologist, and others), "email" isn't necessarily that. It's whatever Google/Outlook/... does for them. It isn't a concete set of protocols. But a _type_ of messaging. A particular set of ergonomics.
When framing it from that perspective, people (programmers?) will go "well duh". Then we can move on from the unproductive discussion about semantics and move on to defining new standards, clarifying threat models, and building a real replacement people and companies will adopt. It'll take a lot of coordination and cooperation that can't happen until we've convinced enough people what the real problem is. And as long as we're using vague, subjective terms like "email", I don't think we can.
Nobody is going to adopt a new email standard that lacks the problems SMTP has. People will instead build new secure messengers that come closer and closer to the ergonomics of email, and that's what people who see a future for "secure email" should be looking towards, not some doomed effort to get the Internet to migrate to a new email protocol.
Hmmm perhaps. But while we keep calling "email" the problem, we limit ourselves to creating "not-email". That's an admittedly large box, but when $politician and $businessperson is still addicted to "email" and asks for it by name, you can argue as much as you want, but not get 100% traction. It is a people problem. A naming problem. A publicity problem.
IMO, better to leave "email" open as a generic term, with the hopes that one of these new messengers (hopefully, Signal) can eventually be standardized and opened to other implementations for adoption inside $bigcorp.
I don't know what you know, but I can say that Signal and Signal Protocol have protected so many more messages than PGP that, by comparison and to a rough first approximation, we could say that PGP has protected effectively no messages. Signal isn't even the most popular messenger with end-to-end encryption, and its uptake so far outstrips that of PGP email that the two aren't even comparable.
So appeals to the email userbase aren't especially interesting to me. My concern is that nerds are continuously trying to convince normal people that they should be encrypting email. That's dangerous, and wrong.
Look, your article reads as a general attack on (encrypted) email. Independent of how it is implemented. You mention "PGP" 7 times: 5 times buried in the last paragraph of the intro, 1 time in a random paragraph on key rotation, and 1 time at the very end, as if your entire post was about PGP specifically. Hell, your title doesn't even mention PGP.
You mention "identity" 3 times, "metadata" 5 times, "keys" and "plaintext" 9 times each, "user" 11 times, "messages" 23 times, and the substring "encrypt" a whopping 41 times. IMO that "plaintext" and "PGP" are roughly equal in usage--and that "encrypt" dominates that!--says something far stronger. Here you're here saying "this post is about no PGP" and I'm saying "but you wrote no (encrypted) email".
I'm in agreement about PGP. I'd even go a step further and say you could say any encryption scheme on top of or underneath email would be weak. (Filippo's age? Jason's wireguare? $unicorn? etc.)
Why? Because of the concerns you enumerated in the post that are fundamental to the way the above RFCs work.
---
Think of the numbers and relative scales. x < 0.0001% of email users encrypt using PGP. and LARP. Fine. Attack those users in your blog posts and comments. But y >>> x of emails users play some part in replacing email in the grand scheme of things, with a more secure alternatives.
The expected impact of writing a blog post and convincing ~nobody to quit using PGP is much, much smaller than writing a block post and convincing someone to start consider building, investing in, or supporting others to build that replacement.
And IMO, you're 99% of the way to the latter, and 80% of the way to the former.
I can't say this any better than the article already does. If we replaced PGP with Age (a cryptosystem I like), email would still not be safe --- for all the reasons the article gives. This is not simply an argument about PGP.
tptacek:
> This is not simply an argument about PGP.
That's what I was just saying... Go reread it!
But you also wrote:
> My concern is that nerds are continuously trying to convince normal people that they should be encrypting email. That's dangerous, and wrong.
I'm (just) trying to convince you to broaden the stated impact of your post. You're wanting table scraps from people who won't listen and who have no impact in turn. Ask for something bigger from people who might but have lots of impact when they do. You're nearly there.
> I don't know what you know, but I can say that Signal and Signal Protocol have protected so many more messages than PGP that, by comparison and to a rough first approximation, we could say that PGP has protected effectively no messages
I can believe it about Signal protocol, since it’s implemented on Whatsapp and Facebook Messenger. But, if you talk just about Signal proper, are you sure it protected more messages and more people than PGP?
I see this claim fairly often, but no data to back it up
Anecdotally I've received e-mails from two people with S/MIME or PGP signatures and zero encrypted e-mails. There are about a dozen people in my contact list with Signal, some of whom I exchange messages with regularly.
It is causing issues for forensics (before that people were using SMS, IMAP, and SMTP; all without TLS). It isn't fool proof, for example if your adversary can gain access to Google Drive or iCloud via a warrant. Although making backups via such platforms is optional.
> IMO, better to leave "email" open as a generic term
Be conservative in what you do, be liberal in what you accept from others
If you attempt to redefine the term 'email' to be something broader, then you will inevitably be breaking and/or confusing users who expect the current implementation.
The current meaning of the word is simple and useful. Given someone's e-mail address, I can be reasonably sure of a way to send a text that will be received.
A world where 'e-mail' means a family of incompatible (by necessity, if we're enforcing secure communications) implementations would be worse than today.
Would you, in ~10 years, prefer a new standard (Signal-Mail, RFC 424242) and have "secure" (for a given definable threat model) standard called email that obsoletes the above RFCs and has 80% market share over current email standards...
...or have 30 different walled-garden, not-interoperable, partially-working (for a given ergonomic use case) apps?
Considering that much of present day communication happens on async on email (including important conversations inside and between banks, governments, land-lords and tenants....), I'd say its something that should happen. And if we can convince the right people, it will happen. We'll live for the next ~5 years in a state of hell (just like we do when we upgrade TLS protocols), and then for the majority of people, things will get better.
Users don't care. They'll use whatever is given to them, as long as there is no friction. That's why PGP-encrypted email never took off, except as something that tptacek likes to argue against.
Concretely, we (the security-conscious community) need to convince people (engineers, executives, managers) at Google, Microsoft, Oracle, countless other companies, and a myriad of open source communities that this is something important to build, invest, and collaborate on.
The first part is messaging. Then comes networking, convincing individuals in private. Then comes public collaboration. Proof of concepts, test networks, RFCs, production apps.
But until there's a need and money, this won't happen. And it'll be people arguing past each other on the internet.
> ...or have 30 different walled-garden, not-interoperable, partially-working (for a given ergonomic use case) apps?
In having to choose from about 5 to 6 that I have to now, it would certainly be a nightmare if it fragmented to 3 dozen or so. That would be a major problem.
> If you attempt to redefine the term 'email' to be something broader, then you will inevitably be breaking and/or confusing users who expect the current implementation.
An interesting parallel could be Apple's introduction to iMessage in the Messages app, to the point where many use the word "text" to actually mean "sending an iMessage".
This is the same problem faced by another worthy goal, replacing DNS. What does cipherboy.example.com even mean, without DNS? Similarly, what does cipherboy@example.com mean without SMTP?
It's a hard problem. If I tell someone "my email address is samatman@newawesomeemail.com, no, you can't email me from gmail you have to use AwesomeEmailClient", they're going to be confused and nonplussed.
If they can email me from gmail, well, they will. And I have to reply with SMTP, and nothing useful was accomplished.
What is a worthwhile replacement to DNS? We don't have one. That's part of the problem: differences of opinion.
Try HTTP/HTTPS: we have separate ports, browser preferences, and lots of unified messaging deprecating HTTP.
Suppose we reuse the same format (name@dom). What would a migration plan look like?
Early stages:
- DNS record indicating support.
- Separate ports.
- Reduced spam (because nobody is using it).
- No warning messages.
Mid stage:
- Lots of dual-stack systems.
- Something like HSTS and preloading.
- Warning indicating insecure delivery (the client can detect this).
- Buy-in from most large corps (Gmail...)
Late stages:
- Old, insecure port goes away almost entirely.
- Revisions to spec, improvements.
We're still at the tail end of this for HTTPS, and we're building on top of a well-known, supported encryption protocol (TLS, which gets reused elsewhere).
The point is, if Gmail doesn't buy in, you've not made meaningful progress, because they have billions of users alone. And unless they move, most large corps/... won't also move.
That's, in my opinion, why Signal and stuff (while nice, secure, ....), won't replace email.
So how do we get there?
First we need a security protocol with the constraints outlined in the post.
- Forward secrecy,
- Handles key rotations,
- Notifies of device changes potentially.
- ...
That's going to take time to design, develop, and standardize. Whether we tie the messaging protocol and format (SMTP/...) tightly to the security protocol (TLS) remains to be seen. It takes time for formal verification too.
Then we need Gmail support. If it is a closed, non-standard protocol (like Signal), it won't be adopted. The RFC process is the only process I know that can influence those types of changes.
And yeah, now? It won't be secure. But we'll have a path from getting to "mostly plaintext" to "mostly secure". And we'll have to live with the fact that it takes time.
If you're not reusing the same address scheme, then yeah. You would have to educate a lot of people about the difference. But if you push that onto the developers, I think that's better. And you can make it mostly transparent to the end user, except at critical times.
Can we also stop pretending Signal was some genius stroke that happened in a vacuum? With all due respect to Moxie signal was born out of years of experience with OTR and SCIMP for XMPP and the need for asynchronous key exchanges in chat systems.
Sure: is there a specific place where you feel I've done that? I think everyone involved would happily concede that Signal, like almost everything, stood on the shoulders of giants. It seems fine to both acknowledge that and also say that making it more accessible (literally go install this thing from the app store) and developing it further (the Signal protocol builds on OTR and SCIMP, sure, but Axolotl, 3XDH and the formalization of Noise are meaningful developments that also warrant recognition).
The thing that's hard to swallow is that you're recommending a plan that maybe solves the problem by 2050. Remember, STARTTLS was standardized 22 years ago and you still can't reject emails from servers that don't use it unless you're okay with missing business-critical messages, in my experience. Meanwhile, Signal works today. It would be cool if there was a group working on the solution you've laid out, and maybe it'll still be relevant when it arrives, but if you have any privacy needs before you retire we have to point you at Signal.
Sure, but HTTP was started in '97, and yet we've gotten a decent replacement rate towards HTTPS.
It's all about publicity and messaging. We made an explicit, coordinated push to get rid of HTTP. We're still working on it. Think of how many people were/are involved.
We've not had a coordinated push for SMTP. TLS doesn't satisfy anything but a trivial threat and trust model (for secure messaging, when done at the SMTP layer). And that would involve a lot less people if we get it "right" (and it's only a new protocol and not a new app).
If it were up to me (it's not), we'd have a solid technical spec and then try and make this happen. Rather than pushing STARTTLS.
There is kinda a group working on a solution. I don't know what the current status is and what their funding levels are:
Sure, but it seems to me that improving email is more similar to improving email than to improving HTTP. I think the STARTTLS push has gone more slowly than HTTPS for reasons that are fairly fundamental to email - it requires hitting more providers to get decent coverage. Chrome has >60% market share, while GMail is <30%.
> when $politician and $businessperson is still addicted to "email" and asks for it by name, you can argue as much as you want, but not get 100% traction
Since it's obvious that no on-the-wire compatibility is possible, it's fair to give it a new name for branding/marketing. Sometimes the progress happens that way, the new name becomes fashionable with $politician and $businessperson and using "email" now signals your low status, etc.
BTW, the new-non-email could facilitate fighting spam and attention-fishing through some micro-payments scheme.
What we need is something with the interface of outlook or gmail, where you can send messages and attachments to address much of the form username@domain.com where delivery of the message is under control of the owner of 'domain.com'.
One use case I don't see mentioned, though, is "I sent you an email that I think you might tamper with the contents of. By doing authenticate and then encrypt, you might be able to claim you never got it, but I prevent you from claiming the email to be different than it is."
You can generally just claim that it was never signed, so you usually need some other mechanism (technical or legal) anyway. This does work the other direction (term of art “non-repudiation”), where the sender can’t claim the message wasn’t theirs or said anything other than what it said. That’s generally considered an undesirable property for messaging systems (because the privacy trade off) but as you point out there are use cases.
>Ordinary people don’t exchange email messages that any powerful adversary would bother to read, and for those people, encrypted email is LARP security.
We are literally living in an age where the NSA is spoofing cell towers to intercept and save unencrypted (and probably encrypted) traffic to a database that will probably be around as long as the NSA exists. This is naive and everyone should be taking precautions against the kind of power that a true authoritarian government would literally kill for.
I'm also personally insulted to be accused of LARPing for taking steps to preserve my privacy. Even if something like protonmail isn't perfect, assuming it isn't compromised it's orders of magnitude better than outlook, Google, et al who are literally scanning your messages.
Edit: let me clarify my point, because people seem to be misinterpreting what I'm saying. The fact that encrypted email is partially broken does not mean that it doesn't currently reduce the leak surface. If I send 5 emails from a service like protonmail to @outlook.com and 5 emails to @gmail.com, that's two fractured datasets vs sending 10 from a Gmail account where they're all scanned into one database. Locks are trivially picked but that doesn't mean I'm LARPing to everytime I leave my house and lock my doors.
If your adversary is NSA, and your defense is Protonmail, you are literally LARPing. You don't believe Protonmail protects you from NSA; the reason you're using it is because you know what you're sending and receiving isn't interesting enough to target. If you had real secrets, you would not send them through a Protonmail-encrypted email; you would make other arrangements.
You're ok with Google and Microsoft building a profile of intimate details on everyone who uses their services?
This isn't about having an adversary now, this is about minimizing future risk. A database of personal data is one index or scan away from being used to Target someone. Imagine what the Soviet government could do with information about your purchasing habits, organization membership, political leanings, religious participation. It's happening right now in China.
The fact that you don't have anything nefarious to hide doesn't mean you shouldn't be worried about the existence of such databases. I'm not hiding drug and weapons deals from the NSA, I'm trying to minimize how much information about myself leaks to people who have no business collecting it. All people should be similarly cautious. Unfortunately this isn't the kind of thing that matters to most until it's too late.
How many laws or executive orders or judge rulings do you think it would take before even the U.S. government could trivially abuse such information to target someone? What if you're a whistleblower like Assange? What if you piss off the wrong police officer? You haven't heard of corrupt cops harassing citizens and who stuck their neck out a little too far?
Bad actors exist all over society. It is only rational to minimize the amount of ammunition they may have against you, even if you aren't planning anything nefarious. The problem with this kind of digital surveillance, regardless of whether it is by government or corporation, is that the stored data is permanent and easily harnessed. Let's not even get into the power that such bits and pieces confer to actors with access to even simple ML technology.
I don't understand the reaction that people seem to have toward the desire for maximizing privacy.
I honestly don't care what superficial steps you take towards minimizing dragnet surveillance. Go right ahead. My problem is with communicating to ordinary people that encrypted email is reasonably safe to use to protect secrets. It is not.
It's substantially better than nothing, is it not? Do you disagree that it requires more effort on the part of a malicious actor when emails are sent from on ostensibly encrypted email service?
Do your house doors not have locks because locks are easy to pick?
Further, wouldn't encrypted email, even in current implementation, be much more effective in keeping secrets if everyone used it? You can do much less with metadata than with email contents, and the fact that leaks of plaintext archives may happen eventually doesn't mean that all archives will be leaked.
The article has a valid point but shaming people by accusing them of larping is IMO irresponsible.
Encrypted email is not substantially better than nothing in the cases where security actually matters. If the metadata of your message can get you arrested, or if an accidental plaintext reply to a message can get your bank account zeroed out, then using a system that carries those risks is worse than nothing. When we talk about secure messaging, those are the use cases we must consider.
I agree with the points made here but based on my experiences I've not yet seen anything that could replace archaic solutions like email and SMS for me. Here's what I've tried and why it's failed:
(Note: This is an "everything sucks" type of comment but it's solely based on my opinion and my experiences. I'm not trying to devalue the work of the people who made the respective solutions and I'm not trying to frame this as general truths. I'm sure a lot of what's listed here just comes down to my specific circumstances.)
- Signal: Afaik it requires a smartphone (Android or iOS) and a phone number which are two things I don't wanna be bound to. Additionally, last time I tried it, messages got noticably delayed and I didn't recieve any notifications. I assume this is because I don't have the Google Services Framework installed even though I checked and Signal should (?) work without it.
- WhatsApp: Metadata falls rights into Facebook's hands so no thanks.
- Matrix+Riot: Message delivery was kinda wonky and slow when I tried it. Also it looks incredibly complex which means someone I communicate with will inevitably screw up just as described in the article.
- XMPP+Conversations: This actually looked like it works for a while. What drove me away from it in the end was that file transfer didn't work for some reason in my environment as well as push notifications for some people I talked to. Presumably they ran a version of Android that mandates Firebase Cloud Messaging and Conversations doesn't use that. We did not want to delve into debugging this further.
- other (mostly "decentralized web") solutions: Message delivery was either unreliable, slow or it straight up didn't work. (No hate on the dweb though.)
Email is kinda bad but so is everything else. What kind of solutions do y'all use and why? Is there some "promised land" I've missed?
Telegram is a joke. They roll their own encryption, screwed it up massively on Day 1 in exactly the ways that everyone who says "don't roll your own encryption" predicted they would [0], and make snake-oil claims about their security while responding to legitimate technical criticism with conspiracy theories about how their intelocutors are all agents of the U.S. government.
Telegram requires a phone number and the server code is completely hidden away from you which does not exactly evoke trust.
Wire might be a good contender. However, last time I looked at it I wanted to stick with options I could confidently self-host and Wire looks way too complicated on that end. (The recommended way to do it is over Kubernetes which is something I don't wanna touch in production.)
I send an SMS every few months, the vast majority of my messaging happens through Signal or iMessage.
And yeah, Signal isn't exceptionally reliable, I've had messages go missing for hours and even days. I hope it gets better, I'm willing to put up with it for security's sake.
I'm not sure I understand what SMS can do that Signal can't, the difference can't possibly be that Signal requires a phone number, can it? And SMS does nothing to indicate delivery and used to lose my messages all the time back when I relied on it.
Keybase might be worth a look. The only complaint I have is that there seems to be no way to self-host it (which is an option I'd like to have.) And the server source seems to be hidden from public which is not great for trust.
The network effect doesn't really concern me. For communication with strangers I'll have to fall back to email anyways since WhatsApp is virtually the only thing that has presence in my area.
SMS works fine for me for some reason. You're right in that it's really bad though. I use it because it's the only thing that even really works at the moment but I wanna get off it as soon as possible.
I think your review isn't that far off. But looking at your other comments you kind of mix requirements all over. For example your beef with WhatsApp is Facebook owns the metadata, but when someone says Wire you say it's too hard to self host. But somehow SMS is fine.
I think you need to separate them by requirements. But anyway for all purposes Moxy and tptacek keep touting Wire is way better.
- It's not tired to a phone number, but can be if you want to. Meaning finding connections is just as easy.
- it uses signals encryption
- it's message delivery is better than signals
- It's UI and UX is a million times better than signals. I let my mom use it years ago already. And you looking pretty actually matters to a lot of people.
- The Desktop messaging usecase is properly addressed even for a business setting. Signal feels like a crappy SMS client for desktop on desktop
I have no idea why these two people write the things the way they do, but unfortunately its looking less like a let's get people to use the best solutions and more like smear pieces for everything that is not signal. It's really too bad.
BTW signal as a messaging client when you frequently switch countries is such a horrible citizen on my phone and judging from peoples issues I'm not the only one who has that problem.
- If you have multiple sim cards god knows what you cannot just reply to messages since it will just send from the wrong one.
- If you're in an country with a sim that doesn't send the country code with system messages and it differs from your signal number the country will be detected wrong. Replying might cost you. Everytime I upgrade signal I kinda hope it's fixed, but they might as well just put a wontfix label on it.
You're right I never stated my requirements anywhere. Ideally I would want something that:
- works (with push notifs and instant delivery and file transfer)
- is secure (ideally E2EE that's established and maintained, if I control the server just TLS might suffice although it's probably still safer to push trust to the edge)
- is Free/Open Source all the way through
- is self-hostable in a managable way (I have some but not a lot of knowledge in running and administering services and I'd rather not shoot myself in the foot with something extremely complicated.) Bonus points if there's service offerings I can fall back to.
- isn't bound to phones or phone numbers
SMS doesn't fulfill these requirements, I simply use it because it's the "universe default" in terms of instant messaging. And I assume telcoms are so regulated that they technically could but legally aren't allowed to spy on me. For that I had a glance at my national telcom laws and while I'm not a lawyer it certainly sounded like they aren't allowed to spy on me unless I'm already in legal trouble.
So the general advice seems to be, stop using federated protocol and start using... signal?
I find it hard to believe that an app that runs in electron and falls for basic web security 101 XSS exploits[1] is a more secure solution than using an encryption layer on top of a federated protocol.
Somebody has had a really bad weekend in a muddy field apparently. Also real LARPers don't want sharp swords, the whole point is that it's not actually dangerous - no edges, no points, nobody is supposed to get actually hurt.
I'm more optimistic than this blog post allows for. I see email's trajectory over my lifetime and it looks like incremental improvements really do work, they just aren't fast. And I think just as Signal lacks an "Encrypt" button because that's the wrong UX (everything is always encrypted, no need for a button) that's email's future too. You aren't going to install "Really good privacy" and have encrypted email. Just one day perhaps many years from now you'll be debugging a weird problem and you'll discover that without ever noticing it your email is actually encrypted end-to-end and you're not actually sure when then started happening or how.
Candidly: I've never LARPed or even watched anyone LARP. I just assume they're swinging foam swords at each other's tin-foil armor. That's as sophisticated as the analysis behind my choice of words is.
> your email is actually encrypted end-to-end and you're not actually sure when then started happening or how
That seems to be the vision for Autocrypt [0], although it seems that the current "Level 1" of the technology is "single-click" encryption rather than the ideal of zero clicks.
Y'know, you can have all the valid points in the world and still come on a _bit_ too strong.
I get the point the author is making re: LARPing, but this kind of attitude and tone is bordering (or, bluntly: is) condescending to anyone who doesn't know as much as you. It's a huge shame because the general discussions surrounding privacy/security are absolutely rampant with paranoid bullshit, and stuff like this just doesn't help. The people you consider to be LARPing might honestly just be new to the idea of security/privacy/encryption/(insert your label here) and would be better served by a tone where you're not talking down to them, especially if you're an established authority.
Personally speaking, I use encrypted email for my personal account - but I'm under no big illusions about it, and at this point it's partly out of laziness as I find moving email providers to be a useless exercise in wasting time. My original use case was my wife and I wanting to send documents back and forth easily, have it encrypted and retained somewhere that's (relatively) easily searchable, and isn't one of the bigger email services. Email is a workflow that goes back decades, and I'm not particularly interested in changing that mental mapping in my brain (a feeling I suspect many would echo).
It's email. It's not encrypted or 100% private if I email my buddy who's using Gmail/etc. It does jack all for my bills, newsletters, and so on. I'm not worried about the metadata not being encrypted because if I needed that level of security, I'd use Signal or some other tool.
You're probably right that it can't be "fixed", but there's also nothing wrong with attempting marginal improvements until an eventual replacement comes along. It remains a convenient "it just fucking works" and until something replaces that, and interoperates with the rest of the way the world actually works, it's probably not changing.
We are condescending† somewhat deliberately. It's time to start shaking proponents of encrypted mail by the shoulders. We need analyses that spell out the concerns starkly and don't equivocate, because the issues themselves are stark, and a nuanced discussion (if one exists) cannot be effectively communicated to ordinary nonspecialist users.
In a world where encrypted email was popular and no reasonable alternatives existed, the equation would be different. But modern secure messengers have lapped PGP and S/MIME a practically uncountable number of times. I don't know what large power of ten the multiple is of messages protected by Signal Protocol compared to PGP, but I do know that it's large. The risk is not that people will naturally gravitate towards encrypted email (which is in practice a nightmare to use), but that well-meaning but poorly-informed technologists will try to talk them into doing that and adding encrypted email to the basket of tools ordinary people use. That can't be allowed to happen.
I also want the analysis to be somewhat bracing for technologists. I'm not making fun of PGP users when I say they're LARPing. I'm describing reality directly and meaningfully. I don't think proponents of encrypted email have really thought through why they're using PGP and S/MIME, and why they're not terrified of metadata collection and the occasional plaintext reply. Their risk profile is not the risk profile of the public at large; when you're LARPing, it doesn't matter if you get hit on the head with the sword.
† Not the term I would choose, but let's stipulate.
I think a fairer comparison than LARP is martial arts training. As you say it mostly doesn't matter if you get on the head, but people think they are preparing for a situation where it will matter. And in most cases they are wrong.
If that's what encrypted email was, I'd agree, but it is not; it is more akin to taking a children's martial arts class for a month and then physically resisting an armed mugger.
You may be missing that most martial arts people practice are for exercise and social display, not for self-defense or killing.
If it has katas/forms, if certain moves are proscribed during sparring, or if your teachers have not told you the catch-22 about there being no morally acceptable way to practice genuine kill shots even though they're all that really matters, then you are not preparing for self-defense in a life-and-death struggle.
So, martial arts may be the appropriate metaphor.
Disclaimer: My knowledge here is limited to a few years of kung fu as a kid, a lot of armchair research in the past five years, and an old friend who used to place at multi-state competitions. I'm not an expert so I could be off here.
> ...but that well-meaning but poorly-informed technologists will try to talk them into doing it and added encrypted email to the basket of tools ordinary people use. That can't be allowed to happen.
This is already happening, which is why I disagree with your messaging: I don't think the way you attack it will fix it, because the people this post will resonate with already (generally) agree with you. But I digress...
I view encrypted email as services like PM/Posteo/whatever paranoia induced flavor of the week fits here. I don't know anybody who tries to use encrypted email straight up - I think the era of running your own mailbox is gone so I don't particularly count it for anything. If you do it yourself, it's a shitshow; if you're on one of those services it "just works".
You can shake the shoulders all you want, but people use email, and people look for the easy win. "Encrypted email" is easier for the average person to latch on to than the UI/UX most secure tooling has right now (a problem even you've noted: https://news.ycombinator.com/item?id=21897173). It's very telling that nothing has dethroned it yet.
Given that, I welcome these marginal improvements while something better is built. These things shouldn't be around in ten years, they're bridges. Email simply has an annoyingly odd usability bar to clear, and nothing is really close to that right now.
If I had to make a dumb analogy, it's like Objective-C and Swift: it's very, very clear that Swift is the future; inherent advantages abound, and much more difficult to shoot yourself in the foot with... but in lieu of Swift, I'd still sooner write Objective-C over straight C, warts and all.
Tell us your threat model. You talk about overthrowing evil regimes, organized crime, first world police and google as though they all do the same thing.
If your adversary is going to drop you, your family, neighbours and cat in an acid vat disappearing messages aren't going to save you.
If your threat model is organized crime, signal might be an ok solution, if you have messages set to disappearing faster than you would tell them your password after they start sanding your feet off.
If your model is first world law enforcement I hope you or anyone you care about have never committed any crimes ever because you will have the book thrown at everything you might have done: https://www.goodreads.com/book/show/6611240-three-felonies-a...
If your model is google, then encrypted email is perfectly valid and a wonderful way to use gmail.
Here's the problem with encrypted email: there is only a very, very narrow threat model that it (additionally) protects against.
In any sane setup, your (and your recipient's) email client will use encrypted connections to and from your respective email servers. Any competent email provider will use MTA-STS, ensuring that no one but the sender, receiver, and respective MTAs can read the message [1]. All this happens for regular unencrypted email, without any effort on the user's part.
So encrypted email purports to drop the ability to allow the MTAs to read the email. But... they don't really do that. Your email providers are required to MITM all of your email, and can trivially modify any plaintext attribute they want to. And anyone who has credentials to your email account can also trivially MITM all incoming email (and may be able to at least social engineer outgoing email, if not MITM as well). This means that pretty much any key discovery mechanism that allows an unencrypted email to initialize or update a public key is defeated [2].
So, encrypted email only provides extra security in those cases where: a) keys are negotiated completely external to email (in which case, why bother with email?), or b) you trust the email provider enough to not try to intercept your messages but not enough to not look at your messages without your permission. Given the BOFH principle (i.e., administrators have no inclination to look at your email because you're boring), that kind of means the second case doesn't really exist as a practical concern. You can improve your security in the second case simply be deleting emails from the server immediately, again not requiring encrypted email.
So... why bother with encrypted email? Unencrypted is secure enough unless you're paranoid, and if you're more than very slightly paranoid, encrypted email isn't secure enough.
[1] This is all happening via TLS, which has gone far, far further than PGP or S/MIME have in actually making "no one can read encrypted text" true. The latter protocols take the stance that "using the cipher.encrypt() is good enough," which has been known to be false for decades.
[2] And DANE-PGP is right out, because your email provider is of course the one publishing your public key.
SFTP shares only those three letters with FTP but is otherwise a completely different protocol.
It's also a counterpoint to one of the OP's points which is that trying to secure email is a dead-end that we should give up on. It may be possible, though very difficult, to transition to secure email. But it would have to be a brand new protocol not tacked-on to the current system. The way that SFTP is the appropriate upgrade path for FTP and not FTPS.
The interface of sftp is largely the same as ftp. You can give someone an sftp client, username, and password and they wouldn't be able to tell the difference.
A new e2e protocol that works just like email does would be excellent, but we don't yet have that. Signal &co are chat apps with a different feel and purpose and other than matrix and xmpp not federated, which is a non starter for many entities.
There are some things we could easily give up to get encrypted mail. For example, setting a max delivery time to allow ephemeral keys.
But there are other problems with encrypted messaging, and I'm particularly thinking of spam. How does Signal/WhatsApp manage to keep a lid on it? Would that be possible in a federated system?
I hope there is no such thing because that would be insane. If you mean SFTP, that's actually a completely different protocol and is part of SSH.
If you mean FTPS (which I suspect you do as I actually had to set up something similar at one time), that's FTP over SSL and has nothing to do with SSH.
Your point still stands though: some of the background "FTP a CSV file with a cronjob" crap that goes on in the background would horrify anyone.
fwiw keybase supports simple and easy signatures (and less verbose than PGP.) combined with an (imo) much more rational and discoverable attestation of identity, I think it's nearly ready to supplant PGP for this use case. email integration for signatures would indeed be nice.
Mind you, unauthenticated encryption in terms of signal does not mean that anyone can forge a message, rather that you can't prove to a 3rd party that this was a message sent by the sender rather than forged by you.
a) DH scheme was invented specifically to solve this problem. And, yes, I could pass my public key via other means, which is not as convenient as e-mail. Including paper card in anti-tampering envelope, is I'm paranoid enough.
b) I'm my own email provider, but I don't trust my server provider (they could read HDD of my server), for example. Or my recipient's provider.
DANE is only an option if your zone is DNSSEC signed and you have control of your DNS. Of course, there are other ways you can go: https://slxh.nl/blog/2016/pgp-and-dns/
You’re in control of publishing your public key, not the email provider.
I’d be remiss if I didn’t tell you how bad MTA-STS is:
* MTA-STS: compromise for the DNSSEC-challenged
* Still can and should prefer DANE outbound
* Authenticates domain control via CA leap of faith
* Vulnerable to MiTM at cert bootstrap
* Vulnerable to weakest root CA, and unauthorized certs
* Open to downgrade on first (or irregular) contact
* Complex mix of HTTPS, unsigned DNS and SMTP
> You’re in control of publishing your public key, not the email provider.
This is only true if you personally fully own the domain and have control of the DNS and other services, which is not the case for the utter majority (at least 99.9%, maybe a few more 9s) of the population. Of course, in that case, you are pretty much the email provider, so not trusting the email provider is a pretty questionable scenario at that point.
> MTA-STS: compromise for the DNSSEC-challenged
Yeah... DNSSEC is a classic example of a solution looking for a problem. Most of your criticism would apply equally well to not using DANE for TLS, and every browser vendor has looked at it and decided against it because it adds no security.
If that were the case, browser vendors would have helped push the DNSSEC chain-extensions forward, which were designed exactly to avoid doing DNS lookups to carry DANE records. Instead, the browser vendors laughed at the chain-extensions effort, and it died in committee.
It is not. Unencrypted is environmental pollution that need to be actively prevent until it reach zero use. A favorable future is one where the firewall blocks any unencrypted traffic by default.
Similar, giving third party clear text copies of private information is not secure. It is never going to be secure, and the only half working solution there is the kind of heavy legal regulations and systems that does not exist anywhere yet.
If people want to debate over which end-to-end encryption scheme is best then they can do so as much they want, but in the end the goal here is to stop plain text from continuing harming people.
You managed to cut out the key word in the quote: unencrypted is secure enough.
Email is protected with TLS on all every hop if your provider is competent. My point is that this protection is sufficient for most purposes. Where it is not sufficient, email encryption doesn't actually add the protection you probably wanted (this is the what the original article is detailing).
The optimal provider in those cases is oneself, running the email on an disk encrypted server, using dane, dnssec, and strict dmarc policy to match (should be noted that the author of this article are also against some of those technologies, and if I recall right, also against people running their own email server).
Project like freedom box could make email encryption obsolete, but thats not because unencryption would be secure enough. It would be because the encryption would be moved away from the individual email and onto the whole server.
Yes, because the security from using Gmail is higher than what you will get for running your own server.
Because Gmail does all of those things, and spends more money and effort making sure they do it correctly than you will over your lifetime.
If you have secrets where you believe that, say, a government will extrajudicially lean on Google to access them, theres am equally, or even higher likelihood that you misconfigured something somewhere and leaked your data.
I have a hard time to see any use case where no security is different from giving google a plain text copy of a private conversations where google has the right to determine who and how others might participate in accessing it.
Giving google a plain text copy of everything you say in private communication is not good enough security. Anyone working with information that is covered under privacy laws should be held legal responsible for disclosing it to a third party, regardless if that third party is google or a friend at a bar. If it is a doctor, lawyer or government employee the probability of this is close to 100%. If its a company talking to customers, communicating personal data as defined by the EU between employees, there is only a google breach away from being found out and sued.
The only choice is encryption, with the choice between a encrypted server under the control of the person responsible for keeping the information safe, or encryption per email. Which of those two choices one choose does not matter but giving google a plain text copy and calling it safe is just LARP security.
I should mention that here in Sweden there were recently a large political scandal involving the government using IBM as a third party service provider. Sensitive data got sent over the border and outside the control of the government, and it continued for years as those in charged really wanted to believe that "the cloud" could treated as just as secure as running your own servers. The law said otherwise, and when reality came crashing down things had to change. Convenience does not make it suddenly acceptable to give a third party sensitive information, even if that third party is a large international operator who can't do any wrongs.
Privacy is not security. Privacy laws do not improve your security. PGP does almost nothing to improve your privacy even when used correctly (metadata leaks). I have a hard time understanding what your point is. If Google, or whomever, is following the relevant privacy laws, why do you care if they have a plaintext copy of your private communications?
I am talking about the threat model that a person have if they work with information that by law they need to keep secret, which if you live in the EU is basically any personal identifiable information about a customers. There is also a long list of professions that deal with sensitive information and carry legal binding requirements to not divulge to third parties. Typical examples is anyone working in health care, education, government, legal system and so on. I am not talking about meta data but classified or data which if disclosed results in people getting fired and holds legal punishment such as jail time.
Using gmail without encryption in those cases is a security issue and also illegal. A lot of people still use gmail in those cases and google track record in regard to data leaks has meant that few people have been found out. That said it will only take one significant data leak and people will start to dig for all data being sent to google. That day a lot of peoples head will roll.
I would guess without exaggeration that a large enough data leak at gmail would cause a global market crash. There is just too much plain text data containing sensitive information that people would dig into. Not private, not meta, just information which people should not have given to a third party. Google privacy policy does not play a role in that.
> I am talking about the threat model that a person have if they work with information that by law they need to keep secret
Then PGP is irrelevant, you don't email that data around. And even if you are, then you aren't dealing with security, you're dealing with compliance, compliance with legal obligations has nothing to do with, and is often in direct action against, actual security.
> Using gmail without encryption in those cases is a security issue and illegal.
This, almost certainly, isn't true, given that Gmail is a GDPR compliant store. You might need to use enterprise gmail, for the legal requirements, but that's still entirely beside the point. "Use enterprise Gmail" is the solution here, not "fail to use PGP".
It is true that people should not email that kind of data but then we assume good op security. Failure of op security is one of the argument of the author here against encryption. On that note I agree with him. People op security is bad, thus they should not use a third party service provider where the line between legal and illegal is the wrong attachment.
Enterprise Gmail is able to operate as a data processor, but there is a lot of fine details in order to stay within the law. It assumes that the company has agreed to the gmail processing terms and gotten permission from their own customer to process the data in such ways. Again here we hope that op security match the fine line between legal and illegal. (If we want a practical example which I know people do, imagine a administrator of a CRM sending a copy of the database to a new hosting provider. Now a copy of the database exist in the sent folder and an other copy at the email provider that the hosting company use. It is very doubtful that GDPR allows that kind of sharing of the private information. If the file get leaked in a data breach there is high probability of a successful lawsuit for mishandling of the information).
Using your own email server or tools that automatically encrypt everything does however prevent those risks.
What email server do you use that automatically end to end encrypts everything using pgp?
It sounds like you're talking about encryption at rest, in which case Gmail does that already, more securely than whatever you're doing so the backwards approach to compliance is more effort and less secure in practice.
> What email server do you use that automatically end to end encrypts everything using pgp?
I wrote a program to do that, but there is also a package in Debian if I recall right that also do it. On the mail server it looks up keys in DNS and if it founds it, automatically encrypts outgoing email.
> talking about encryption at rest, in which case Gmail does that already
Emails at google is not encrypted. Good must have access to the plain text in order to do analytics and search. If google has a data breach it can include every single email gmail has in plain text, and that is a fundamental risk.
> more securely than whatever you're doing
That is kind of impolite to make assumption about my own setup. It is also wrong.
> On the mail server it looks up keys in DNS and if it founds it, automatically encrypts outgoing email.
So you're not talking about pgp/e2ee, you're talking about, like, SMIME or something.
> Emails at google is not encrypted.
They're at least as encrypted as they are on your server from what you've told me.
> That is kind of impolite to make assumption about my own setup.
Given that you don't seem to understand the difference between end to end encryption, in transit encryption, and encryption at rest, I'm going to say that no, I'm very confident that you haven't done this correctly.
> It is also wrong.
And that therefore no, gmail and Outlook are both more secure than your email server.
I wish more people would study IT security since a lot of this kind of silly discussions are cleared up during the first lecture.
Basic 101 security. In order to calculate risk you take the risk threats minus risk mitigation. The bigger the threat, or the fewer the risk mitigations are, the bigger the risk.
You might have forgotten that in 2010 there was this data leak called cablegate. NSA lost 251,287 diplomatic messages. NSA did store them on an encrypted server, and used transit encryption, and yet the data leaked. A major risk to data security is access, and in that case an administrator with access leaked it.
With my mail server, that administrator is me. One of the larger benefits of personal servers.
When you compare Gmail and my mails server then you include social risk just as much as technical risk. You compare the physical risk, that is servers located in multiple places on the earth. You compare the political risk of a single entity that control 80% of the world email with a private email address used by one person. you compare targeted attacks with passive and optimistic attacks.
Lets put money where out mouths are. Want to bet that google will have a new data leak before I do? Looks like a very lucrative bet to me.
In 2018 Google had a data breach. five million user's data was compromised. In 2018 I had zero data breaches in any of my servers. Zero users data was compromised. I have been running my own server for almost 20 years and not a single bit has been lost.
Have I Been Pwned? has billions of leaked accounts, not a single which belongs to me. What about you?
> So you're not talking about pgp/e2ee, you're talking about, like, SMIME or something.
No. There are RFC for email security written in this century. The adaption of putting pgp keys in dns is not great however which is why personal email servers is currently better, but both solution works fine either way as long both side of the conversation does it.
> With my mail server, that administrator is me. One of the larger benefits of personal servers.
Ah I see, so you aren't actually worried about security, you're worried about privacy. Which We've been over when I said:
> Privacy is not security.
You also are ignoring a whole host of other risks, like data loss (your one server breaks, oops there goes your all of your email, etc.)
> Lets put money where out mouths are. Want to bet that google will have a new data leak before I do? Looks like a very lucrative bet to me.
Sure, I'll bet you $10,000 that my email will not be leaked before yours. Here's what we'll do, I'll tell you my email address, and you tell me yours. Mine is @gmail. Yours is hosted on your server. I'll then turn around and spend $8000 on a pen-test of your server, they'll exfiltrate data, and I'll win the bet and be up an easy $2,000.
> In 2018 Google had a data breach
Pause, hold on. No. In 2018, Google announced that there was a vulnerability that could allow semi-public information to be shared more widely than intended (literally it was things like name and phone number that you put on your G+ profile being shared with a wider than intended audience).
There was no evidence that this vulnerability had been used, and Google's own employees detected it.
> In 2018 I had zero data breaches in any of my servers
that you detected. Here, Google has a better track record than you: they are actively monitoring and red-teaming their own servers and systems to detect vulnerabilities. Do you?
So I'll put it bluntly one more time: you are putting your clients data at more risk by administrating your own mailserver than you would be if you let Google or MS do it for you. You can try to come up with all the counterarguments you want, but they are, as this article puts, security LARPing, not actual security best practices.
You are a bit funny. Just as you can hire a hacker, I could buy a zero-day exploit, or someone could hire mercenary and take down googles servers. It would not prove or disprove anything.
In the end, if you have your email leaked while I do not then that is what matters. Results. I have had zero leaked accounts. Most people have stuff that been leaked, and since you refused to answer, I assume you are listed in Have I Been Pwned?. You trusted someone to be secure and they were not. That was your choice, and it was the wrong one.
I have had the same setup been tested by two different pen testers, so yes, I would not mind that bet.
If you break the law however, which is what happens if a pen test a system without permission, then it doesn't really matter if you hack or use rubber hose tactics. Breaking the law is breaking the law. The police don't look kindly to bets under those situations.
I will also say the same thing I wrote to those two pen testers that tested our system. If you find any vulnerability I will happy help write the CVE report. What I did not tell them but will mention here is that I also happy take part in getting those bug hunting reward money that zero days exploits usually rewards. If you have for example a working exploit against current stable release of latest SSH then I am sure we can turn that in somewhere for a pretty good amount of money.
You seem to assume that the government will need to access all accounts at Google individually, and will have to work equally hard for the first one as for every subsequent one. Why is it not a likely risk that Google is thoroughly "compromised" by the government? We have seen this before, when another company was in a similar position regarding access to user's communication:
I think the point was that you can't protect yourself from your recipient disclosing the information, regardless of your chosen scheme,so it just doesn't matter.
There are schemes that make it difficult for a recipient to accidentally disclose your information. PGP isn't one of them. For example a common enough way of doing PGP is to use a chrome extension that PGP-ifies your webmail. Or to use an encrypted mail service like protonmail or tutanota. In all of those cases, assuming the mail provider is untrustworthy enough that you feel the need to use e2e encryption, they can also just inject JS to steal your plaintext from the client, so you aren't really secure unless you're using an imap client, which by definition you aren't doing.
Good protocols prevent people from shooting themselves in the foot. A good protocol will get in your way if you try to do something insecure. PGP doesn't do that, see "oops I accidentally forwarded the plaintext of my encrypted email" vs. Gmail and Outlook's "confidential" modes, which prevent accidental exfiltration via forwarding or copying. They're possible to circumvent, but you have to make an effort to do it.
PGP requires that you not only not be careless, but be near-perfect, and that every counterparty does the same. Good protocols prevent you from making mistakes that spew your plaintexts everywhere.
In other words, I want a protocol that doesn't necessarily protect me from idiots, but does protect me from humans who occasionally act imperfectly.
It is not problem of protocol. It is problem of user agent.
And, yes, all webmails is incredibly crappy user agents.
Stop using webmails!
On the other hand, UA (for any protocl) which will not allow copy'n'paste from is crappy by definition and nobody could stop your recipient to copy'n'paste plain text from your message. Ultimately, it is THEIR message as much as YOUR message!
On the side note, I think that GMail is worst thing that has happened both to the web and to e-mail.
Secure protocols ensure that user agents are secure, as part of the protocol.
A secure protocol would, for example, not mix plaintext and encyrpted text messages, but would ensure that all messages were always encrypted. This way a we'll designed user agent couldn't accidentally mix cypher and plaintext messages.
I'm not arguing that UAs should do user hostile things in the name of security, which is the straw man you're arguing against. Nor did I mention anything webmail specific.
I'm saying that a security protocol shouldn't have, in practice, fail open attributes that user agents have to put warnings up about. A good protocol should allow the UA to entirely hide those dangers.
This is abundantly clear if you try to use any pgp mail client vs any signal protocol client. The protocol makes it easier for UAs to be both more secure and more user friendly.
>For example a common enough way of doing PGP is to use a chrome extension that PGP-ifies your webmail.
You mean mailvelope[1]? That's a straight up plugin/extension. It gets installed once and is as secure as whatever is used to secure extensions on a particular browser.
It's one of a number of options (gmail for example had an unofficial official one for a while, and there are other similar extensions). They still all have the same issue that the only threat they protect from is "my webmail provider is incompetent".
No offense, but stuff like this pisses me off to no end. You just assert that all applications are your application and then conclude: and therefore anyone doing anything else is crazy. It's frustrating beyond belief.
The stupid thing is that I know this is not what you actually believe. You say it in the first sentence of the second paragraph of the comment I'm responding to. If this is the tool you have, then it's a tool you can use. If you use it properly and understand the limitations, then it is fine. It's more than fine. It does what it needs to do!
I get that it's extremely easy not to understand how to do things. I get that it's extremely easy not to understand the limitations. I get that it's extremely important to send the message that unless you actually, truly know what you are doing, then probably you should not be using email and OpenPGP to encrypt messages. And in fact, if you have the chance to use something better, you really, really shuold. I get all that stuff. But it is just wrong to imply that you can't send information securely using OpenPGP and email. I mean, it's infuriatingly insulting to be told by a security expert (which I readily and without reservation admit you are) that I'm just playing when I know said expert knows they are exaggerating to push their agenda.
I can even show considerable sympathy for this agenda. I think you do a wonderful job of explaining problems and showing where there are better ways of doing things. You are doing good work! But, stop with the insults, please. It's beneath you. It pisses off people like me that would love to support your cause but are so pissed off with your attitude that I can't bring myself to do so. You are hurting yourself and you are hurting your cause with this line of nonsense.
I am saying the opposite: that nobody should be using this tool, and that the only "real" reason it gets used is for social signaling, and the everyone using it to protect secrets has been misled by the people doing it to signal. What I'm saying in the post is what I believe, for the reasons stated in the post.
And I should seriously implement the Signal protocol on decades old equipment in the middle of a company infrastructure that's on an intra-net, when I can hack something perfectly serviceable instead. Well... I mean... Yes, I should :-) But it's just not reasonable that I'm going to get that budget.
Not every application is your application. Not every fight is your fight. If you absolutely must insult someone, target it and be specific. But, better yet, get your message across without insulting people. It will be much, much better.
I reject the idea that people should seriously consider the shoddy security of encrypted emails so that your "decades old equipment in the middle of a company infrastructure that's on an intra-net" can participate on equal terms with commodity phones that are 2x as capable. That's the quintessential argument for ergonomics over security, and that's the offensive argument, not mine.
Voluntarily removing this message because I don't think it holds with the rules of HN. I wish I could have a productive conversation on this topic, but it seems like it's not in the cards. Hope you have a good day, otherwise.
I didn't see your original message but I'm sure it was well-intentioned and wrong. I am wrong often too. Just not this time.
Taking back an HN post you think will be taken as uncivil is a strong move. Respect for taking the community seriously. There's nothing personal in my criticism of encrypted email; it's the technology I hate, not the people behind it.
Well, I would be remiss if I didn't say that I also take you seriously and respect you. I also don't think you are wrong... at least in the way you are looking at it. I think there are other ways to look at it, though. Still, no excuse for me being grumpy.
This is disingenuous. My wife for example would be fired if she didn't encrypt medical records that she has no choice but to email as part of her job. There are thousands of people in just our US state that she might need to communicate protected health information with. Those thousands of people are not signaling. They would just prefer to keep their jobs.
I have no problem with anyone sending encrypted email because they are legally required to do so. I'm sure there are a bunch more corner cases like that, and I'll have the same response to all of them. I think it's pretty clear who the intended target of my critique is.
Corner case? I would have thought sending secrets via email was more than just a corner case of encrypted email. I don't actually use encrypted email though myself.
People required to use encrypted email may well be majority of users using encrypted email. In that context its for sure not corner case. But in context of all people using email and people looking for more privacy it is for sure corner case.
I think author is advocating for all of communications to be encrypted and it cant be email because its just bad. People should stop advocating for it.
LARP is a popular free time activity with nerds here in Germany. And people will fawn over kit and/or spend money on extravagant but useless equipment to earn social status inside the community.
So I thought that calling people LARPing was actually quite clever, because the reason why I would roll out buggy encrypted email would be the same as for why I'd walk around in a cow leather robe in a forest shouting like a madman. I have done both, btw.
And just like nobody would complain about me accidentally breaking character during LARP, nobody would complain if I accidentally break the encryption by replying the wrong way.
So as someone enjoying LARP and dabbling with encrypted emails, I didn't feel offended by his comparison.
I use Signal on my phone, and I like it for the common situation where I'm close enough with the person to share my personal phone number.
I'm still looking for a solution for the situation when I'm trying to communicate without revealing my identity to the person I'm talking with. Signal's reliance on phone numbers means I'd need to get a bunch of burner phones or something, which is beyond what I'm willing to do: I'm not talking about an ultra-high-risk situation, just I'd rather not announce who I am when I'm interacting with people I don't know that well.
What do you think is the most promising tool for this sort of communication? I've been hearing about Riot/Matrix; do you think that's a good option for people to use?
The idea with Keybase (can't speak for signal) is that your client doesn't need to trust the server. You only need to trust that your client isn't compromised, which is easier to verify.
Sure (and that's true for signal as well), that's not my point. My point is you have to rely on that service being available. And you need to trust it to deliver and (at least with keybase) persist your encrypted data. And if that service becomes as prevalent as email, that gives the organization that controls it a lot of power.
> What do you think is the most promising tool for this sort of communication? I've been hearing about Riot/Matrix; do you think that's a good option for people to use?
> I'm not talking about an ultra-high-risk situation, just I'd rather not announce who I am when I'm interacting with people I don't know that well.
In that case, yes, with some caveats.
Be mindful of your list of Matrix devices because that is something all participants can see. Otherwise, Matrix will allow you preserve basic anonymity with respect to the other participants (but not with respect to the server) with solid encryption.
Also bear in mind that Matrix is built on the premise of storing all messages server-side indefinitely by default (in end-to-end encrypted form and with regular key rotation so forward secrecy is preserved).
Of course, forward secrecy does not help if the participants retain all keys indefinitely and subsequently leak them. I think disappearing messages are in the works.
One option is XMPP with OTP or OMEMO encryption. XMPP IDs are similar to email addresses, it's easy to set up a server, and there are lots of public servers you could get an account on as well.
"I'm still looking for a solution for the situation when I'm trying to communicate without revealing my identity to the person I'm talking with."
This exists. In the past, it took the form of an "anon.penet.fi" email address. This was a very simple, useful service[1] that many people used to great advantage.
In modern times, you can see this very same concept used at craigslist wherein CL maps your email address to a random craigslist email address, allowing you and another party to have painless email back-and-forth without leaking identity.
Now that I am thinking about it, you could set up a simple SMS remailer with codes that would allow the same thing to happen.
None of this addresses secure comms, but that's not the question you asked ...
> In modern times, you can see this very same concept used at craigslist wherein CL maps your email address to a random craigslist email address, allowing you and another party to have painless email back-and-forth without leaking identity
CL implementation is flawed and only gives perception of privacy. I forget the header/tech name for it, but if you hit reply and your email account is set to “First Last <email@domain.com>” it will pass along that entire string to the recipient in the body of the email. The obfuscation is only in the actual email address the message goes through
I don't have a problem with "LARP" as I understood the analogy and having a bit of flair in writing helps make it memorable. Editorially speaking it may be too niche a reference and be confusing. (Reading these comments it certainly has been.)
The condescension I see is in calling out "technologists." I've never heard that before. Just looking at the word it sounds like it means a person who works with modern technology. Wouldn't that encompass the majority of Hacker News readers? But by context you don't seem to have a favorable opinion of the group. What makes someone a technologist to you? Do you include yourself and if not why not? What justification is there for you to generalize people in such an unflattering way?
> We are condescending† somewhat deliberately. It's time to start shaking proponents of encrypted mail by the shoulders.
And yet, you catch more flies with honey than vinegar. Or, in other words (although this is an exaggeration) pulling a Linus to get your point across is counterproductive. The hostility radiating from article will turn off a lot of people who otherwise might benefit from considering it.
Actually no. The title got my attention, and reading through rid me of any illusions I was harbouring about encrypted emails. (Granted, there weren't many left, but anyway.) A title like "Encrypted messaging apps like Signal preferred over PGP" what have been glossed over. At some point you have to tell technologists that their bad advice to people who really need the technology could get the latter killed/imprisoned/tortured.
Not all of PGP is bad though. PGP is really hard to use but it's still useful for signing, file encryption and authentication. Encrypted email has been outclassed in every way by modern messaging applications such as WhatsApp and Signal but currently PGP is the only good way to sign code.
Yeah surely not by Whatsapp / Facebook. It's proprietary code afaik and the possibility of third key exists for that reason. It's not trustworthy at all, especially considering the company owning it, who also told users in the past, that the data of WA and FB would never be merged or used together. WA is laughable in the context.
It is live action role playing. The implication is that they are just pretending to care about privacy by going through motions that are only vaguely related to actual privacy.
As somebody who is friends with some LARPers, I find the usage here to be a little rude. No (sane) larper tries to convince anyone that their world is real, nor do they believe it is real, which is the parallel being drawn
Yes, I didn't get the usage of the term "LARP" in this context too. It comes off as rude and condescending to both LARPers and email users. I am not sure the term fits appropriately in this context. All LARPers are aware that they are role playing in a game, not the real world, and they do not pretend otherwise.
I certainly don't intend any offense to LARPers in general, virtually none of whom use encrypted email. Nor, indeed, email users, among whom I count myself! No, I'm pretty specific about where my criticism is aimed.
To larp as a verb applied to a discussion that is not about actual LARP activities (the primary sense of this word) carries a strong connotation of rudeness.
Etymologically it probably emerged in the infamous *chan-culture, and is in active use there in the sense of ‘pretend play’ or ‘on-line role-playing’. It can be used to signal, in a derogatory way, that you feel that the other is spinning a yarn or indulging in a fantasy, without declaring the fictive nature of their comments, in order to provoke responses and bait others into participating.
I wouldn't use this word in polite conversation, unless you are actually talking about live action role-playing.
1. LARPing is nomenculture in the infosec (netsec/"cybersecurity") world. It means someone is taking security a bit too seriously, like they're in a James Bond movie. They've fallen into delusions and paranoia that everyone has the capability of a state actor, and that all systems and all actions should be considered with this notion in-mind.
If someone is running TailsOS/Whonix/Qubes as their daily driver OS, and only browses from TOR, connected through a VPN/cellphone tether/coffee shop WiFi, with full hard-drive encryption using VeraCrypt+hidden partitions with a killswitch to zero out the harddrive if a certain password is entered, and runs their laptop with no battery, with a CoreBoot/LibreBoot flashed BIOS -- then they are taking this shit way too seriously and will be chided as a LARPer.
Yes yes, I understand security is important -- I used to be a vulnerability researcher who transitioned to "red teaming" for a government agency -- but the above is taking things too far, especially if you're just a layman that barely makes it on anybody's radar.
That's LARPing. It's like when a script kiddie buys a DDoS service, and calls themself a "hacker," for overloading a server (AnonSec/Anonymous I'm looking at you, morons). It's roleplaying, it's childish, and it will get ridiculed for its self-aggrandizing.
2. I don't know why, but everytime someone mentions that they're offended or miffed about something someone else said, especially on the internet, I have a very hard time taking them seriously.
I believe it's because I grew up on hearty banter, and anyone that couldn't hang was, in my eyes, a chode. No disrespect, but I wanted to share that insight with you. Maybe it'll come in-handy somewhere down the line.
1. To the outside world, a LARPer might be indistinguishable from someone that actually needs perfect opsec. Maybe that LARPer in the coffee shop is Ross Ulbricht.
2. If one day you actually need real encryption, it will help if you've LARPed in the past.
One could also use the phrase "cargo culting", perhaps -- carrying out actions that seem associated with a good outcome in a context that provides none.
I think the implication is different - LARPers may or may not be using a useful technique, but they don't really care about the outcome. If they're sword-fighting, they may use actual sword-fighting skills, but they don't really care if they get it wrong and they get hit - it's just a wooden sword.
Cargo-culting implies you recally do care about the outcome, but you don't know how to get it, and the technique you have is copied poorly from someone else.
To extend things, it's true that if you are about to go in a duel to the death and you are preparing by studying how LARPers sword-fight, you may be Cargo-culting during the duel.
People like cypherpunks who like to use sophisticated security tools and encryption to protect their secrets, which generally are messages they post publicly and open source code they put on Github.
Condescension is good in certain cases, especially during public health epidemics. Anti-vaxxers being mocked is good, pointing out that a certain group of people are selling the illusion of faux-privacy in a dangerous way is also good.
It's pointing out that the emperor is wearing no clothes: that they're ridiculous. It may not help someone already too deep to dig themselves out, but it will probably stop at least a few people from getting on the wagon at all; no one wants to look like a fool.
It's interesting that you bring up the emperor's clothes, because shaming people for showing their body is not something that people make convincing arguments for. Observe how countries with advanced civil rights such as Germany have more nudist beaches.
Privacy is a human right, but I think it is a step too far once you ridicule people just because they don't value it as much as you do. There is nothing wrong with being "ridiculous". Who are you to judge who counts as a fool?
Everyone judges everyone, and to judge who is a fool is also something everyone does, a personal judgement that might be shared with the rest. "Who are you to judge" is the wrong phrase. "Who are you for your judgement to be taken into consideration by me" is the real meaning.
Do you not know the story The Emperor's New Clothes? It's a classic where I'm from. From the Wikipedia page:
"The Emperor's New Clothes" (Danish: Kejserens nye klæder) is a short tale written by Danish author Hans Christian Andersen, about two weavers who promise an emperor a new suit of clothes that they say is invisible to those who are unfit for their positions, stupid, or incompetent – while in reality, they make no clothes at all, making everyone believe the clothes are invisible to them. When the emperor parades before his subjects in his new "clothes", no one dares to say that they do not see any suit of clothes on him for fear that they will be seen as stupid. Finally a child cries out, "But he isn't wearing anything at all!" The tale has been translated into over 100 languages.[1]
The point isn't...whatever you're talking about, it's that the people do value it a lot, they're just shooting themselves in the foot.
You need to be strategic about it. I've met someone with anti-vax beliefs, and pointing out her errors without mocking her worked wonders. I believe she actually changed her mind.
We likely need a better globally supported standard. I think Gmail is onto something with the "confidential" send setting, but I don't like that it's tied only to Google.
For my services that use automated emails, I only send plaintext emails and use shortlinks. No sense in wasting time trying to make an email look good on every provider and hope it's encrypted or worry about which ones it will be blocked from because they don't support encrypted.
It should be used as a notification mechanism nowadays. But we do need a better universal platform - maybe that's webpages...
Exactly this is the key point. This why email is still so important because it doesn't lock you into ecosystems. It comes from a time when decentralization was still valued in the internet.
I think only regulatory action could be a way out of the messenger mess (which potentially leak even more metadata). I don't want to be forced into closed telecom ecosystems by my (real life) social network. The problem with potential message routing regulation will be that governments mandate weak crypto for law enforcement.
So I guess email is a dinosaur worth preserving. Even with security after design. delta.chat comes close to an deal world IMHO if you ignore the problem with metadata. Maybe it could integrate sth like mixes to make email a bit harder to monitor.
If we go down the list of compromised protocols, hardware and firmwares/applications in use online (not including the people), how long before those in the know conclude that the Internet is an untrusted medium for secure communications?
I don't think we'll see homing pigeons make a comeback, but using autonomous vehicle couriers for analog/digital communications (drones, but more likely sdc's) and sacrificing the convenience of real-time communications for 100% integrity is not beyond the scope of reason or wants. If a message (or payload) is intercepted, it's physically impeded and much easier to track/detect. The number of layers of security to lockdown or destroy the contents is also at the sender/receivers discretion.
Depending on how cumbersome they choose to make 8k videos, VR worlds and/or new fangled AI/ML datasets for personal/business use, we're limited to 6720 GB transfers per day over 1GB lines, so data outgrowing the Internets transfer speeds is a plausible scenario that may facilitate a use case for local and long-haul direct autonomous data couriers that will blend in with the other autonomous delivery/pickup traffic.
One of my suppliers sends me PGP encrypted email invoices using an automated system. It works perfectly well for my threat model. Security vulnerabilities in processing this may exist, but so they might in every other system; there's no special vulnerability in email or PGP here.
I understand that this article is for the secure human-to-human messaging use case. That's fine; I have no argument with this. But outside that context, it makes no sense, yet generic claims like "encrypted email is bad" are being made. This is too broad.
I understand that the majority of perceived demand* for encryption may be for secure messaging. On that basis, maybe you think it's OK to disparage encrypted email because a win in getting universal secure personal messaging with the modern desired properties would be worth the cost. But isn't this a strawman? Who exactly is a proponent of encrypted email for secure personal messaging anyway? Who is using PGP for personal encrypted communications today who is being harmed?
* Because most people don't care; it's only a minority of advocates who, rightly or wrongly, believe that everyone should.
(In all honesty, I don't believe you. I presume you're paying those invoices, in which case whatever attacker you have in mind can just follow the money and monitor the metadata to learn everything they need to know about those invoices. Or, more likely, your threat model is "nobody's seriously gonna snoop on my payments to this supplier; I just think it's fun to play with PGP.")
I'm surprised no one has mentioned Delta Chat yet. It solves some of the problems, as it's based on email but adds automatic encryption. See https://delta.chat/ and https://autocrypt.org/
For me this is a good compromise and a great alternative to messengers like Whatsapp and Telegram. This is a first step towards decentralization while relying on the existing email infrastructure.
And Delta Chat encrypts not only messages but also metadata, right?
Although only when used properly - again, there's no point in relying on Delta Chat if your correspondent is going to forward your messages to people on gmail.
well, at least the issue says, they can be removed from the easily visible header, so they could also be encrypted.
but smtp will know anyway.
i think, this is a general issue with "who is messaging whom" - also signal, whatsapp, whatever have to deliver the message and cannot know this afaik when these delivery data are end-to-end-encrypted. so this is not only an email problem.
but with email, at least, there is no "global" server that sees everyhing (no, also not gmail outside us :) and can draw a huge social graph.
I really want to use Signal but having a centralized server and requiring my phone number turn me off. I'd love to be able to self-build the iOS [0] and desktop [1] apps, and self-host the server [2]. Has anyone tried any of that, are any of them even possible?
On iOS you'd have to constantly redo it via TestFlight or Jailbreak. You could build and install on Android. But "your" binaries won't connect to Signal servers.
> Yes, you can host your own _Signal server and have your own singed apps but it will have to be your own _Signal network, not Moxie/Signal Foundation's Signal.
I don't think that's quite true. You might[0] be discouraged from running your own self-built binaries, but given that Signal Android has reproducible builds[1], I don't think that there's any actual technical barrier. The context of your links is about having (unofficial) third-party packages for Signal, not about somebody building the binary for their own use, and since these are obviously two different things, from a social perspective, I don't think that the Signal foundation would complain much about the latter (given reproducible builds and the fact that you wouldn't be distributing the binaries, they probably wouldn't even know about it).
For Signal-iOS, it seems that you won't get push-notifications if you build by yourself.[2]
[0] I'm not 100 % convinced that "We would not recommend that anyone use an unofficial binary build" was meant to refer to building for yourself, by yourself.
What's with all these articles dissing the very idea of encrypting email? It used to be that hardly anyone cared. Now there seems to be some effort to discourage something that any reasonable person interested in privacy would enthusiastically support.
This is a pretty typical example from the article of the sort of important sounding but ultimately bogus argument presented in such articles:
>So, for example, it recently turned out to be possible for eavesdroppers to decrypt messages without a key, simply by tampering with encrypted messages.
By failing to actually specify the actual attack the writer hopes to prevent a rebuttal. I am pretty sure they are talking about EFAIL. EFAIL was itself a weird slander of the idea of encrypted email but ultimately did not show any weakness of either PGP or S/MIME. It was instead a cautionary tale about the use of HTML for email.
The article attempts to promote Signal as superior to PGP email. That is unlikely as Signal initially trusts the phone system for identity. It is also quite a lot more complex than PGP so the odds of an exploit are not in Signal's favour.
and was optional. The protocol did not require validation and as a result some protocol compliant implementations were vulnerable.
If a protocol compliant impl is vulnerable, and the fix is to update the protocol, the protocol is broken.
Yes without html you couldn't build this gadget, but we don't blame machine code for making gadgets possible, we blame insecure c for having buffer overflows.
But in use for all the clients that the EFAIL people tested. That was not the problem. The problem was that there were email clients that were loading image URLs from HTML emails. There was nothing to fix in the case of GPG2. It was entirely a problem with the way that certain email clients handled HTML emails ... a problem, might I add, that still exists today. They just prevented the one type of attack. There will undoubtedly be others that may or may not involve encrypted emails.
> However, we found that several clients only gave a warning to the user for invalid MDCs, but still displayed the modified plaintext. This allowed the CFB gadget attack despite the MDC
No, the problem was that clients would render a plaintext known to have been tampered with. This was exacerbated by a zero click gadget, but would still have been an issue if images weren't loaded and a malicious link was clicked.
You're right that Gpg wasn't shown to be broken, but pgp was. (This is the CBC attack, not the direct attacks on clients which are just client bugs, which themselves aren't direct evidence that a protocol is broken)
> By failing to actually specify the actual attack the writer hopes to prevent a rebuttal. I am pretty sure they are talking about EFAIL. EFAIL was itself a weird slander of the idea of encrypted email but ultimately did not show any weakness of either PGP or S/MIME. It was instead a cautionary tale about the use of HTML for email.
What you said there can't be stressed enough. Despite that almost no email client in the past decades defaults to allowing active or remote content. But because you could turn all that on with some clients... it somehow means PGP and S/MIME were impossibly insecure.
Efail worked with the default settings on almost all clients except Mutt. Most email clients do not have a "plain text" mode. They all display emails as HTML and apply some formatting to make the "plain text" mode be monospaced.
Also, one of the Efail exploits (the CDC gadget) was a cryptographic vulnerability. The fact you could manipulate the ciphertext to inject HTML tags such that GPG wouldn't scream bloody murder (because the MDC wasn't required and had very odd semantics, where GPG would output data to the caller before it had been authenticated and clients showed it as a warning and still rendered the HTML exploit) was definitely at its core a cryptographic bug.
All of this was explained in significant detail in the CCC talk about Efail[1].
557 comments
[ 5.6 ms ] story [ 303 ms ] threadHowever, I think it’s possible to have a system completely in the open and still be secure. Bitcoin comes to mind. I don’t think the problem is with email, but with the lax encryption models and the lack of support by email clients and servers alike. Wouldn’t you agree?
Your argument seems to boil down to: "bitcoin is open", "bitcoin can $X", "email is like bitcoin", therefore "email can $X". There are a few flaws in that argument. Firstly, Bitcoin is pseudonymous, it makes no attempt to hide transaction details, which obviously message security would need. Secondly, even if the properties of bitcoin were relevant to messaging, at best you've made the argument that "a system with public transaction records can still do what you need for safe messaging", but not "email specifically can do what you need".
There are two ways I could see your argument working out and both are pathological examples. We can do secure comms over TCP, so just design a secure comms system and then all the way at the end choose a blockchain or email as your transport. That sounds true, but also doesn't seem like a useful thought tool that results in improving anyone's communication security tomorrow.
I did not introduce any equivalence about valuation in my argument. I used Bitcoin as an example of a well known open database, where everyone can see the data (arguably an analog to plaintext exchanges) and yet it's secure.
Additionally, your point about Bitcoin being pseudonymous also applies to email. You may create your own address, on any number of servers. At a high level, it feels like the pseudonimity is essentially the same.
Are you proposing people stop using email and switch to a more secure messaging system, like Signal? Or maybe to make an email app on top of tech similar to Signal (kind of like Protomail?), or to improve email by baking in modern security standards?
The pseudonymity is precisely one of the reasons e-mail does not work well. One of the features of secure messaging as it is commonly understood is participant privacy: hiding who participates and ideally when. This is the metadata leakage problem described in the post.
You're restating your argument of "bitcoin is public and yet it is secure and so it is possible to have secure systems that are public". I understand that, but you don't appear to have engaged with my counterargument: "secure" is not a universal term, and things that are fine bitcoin transactions are not necessarily fine for secure messaging.
Protonmail does not seem like "tech similar to Signal" to me at all. I'm all for implementing stuff like MTA-STS, and I appreciate e-mail isn't going to die any time soon. I think that trying to add E2E-style encryption to e-mail is fundamentally doomed, signing for e-mail is mostly doomed, and yes, private conversations belong on something like Signal.
It’s interesting that you feel email has a lot of traction and is broken, but you see that as an argument for moving away from it. I would think it’s an opportunity to fix that system, since users are unlikely to switch. I’ve thought quite a bit about what making email like Signal would look like, but I’m curious what’s your take on the overall problem.
MTA-STS works because it does not require end users to do anything. If you need end users to change their workflow, you could try to do that with e-mail (which fundamentally can't do all the things you need it, per the post and the PGP post), or you can just make them use a non-broken protocol.
Sure, it’s plaintext, but I don’t see the downside?
At some point you're going to keep adding lipstick to the pig until eventually you have something morally equivalent to the pathological example I gave.
Can we design a system such that sending a message from alice@foo.com to bob@bar.com is reasonably secure and private? How does Signal/NOISE solve this? Why can those not be applied to non-messaging systems (or, at least more traditionally structured messaging systems - which is itself a questionable definition since email threads are a hack, its mostly just independent blobs)?
I guess I'm off to read the whitepapers for NOISE and Signal tonight to see how the models differs.
Matrix is basically an email alternative. Though I think the address format is needlessly complicated. Email is perfectly good at addresses!
Is there anything like this currently implemented / standardized?
Keybase has an even more complicated key escrow-based system (that works for any of their "Proof" types, not just domain ownership) if you trust their clients, where your client generates an ad hoc key for the recipient and essentially a "for bob's ears only" claim and on verifiable Proof from Bob securely exchanges the ad hoc key to Bob's new public key. Which is interesting because it allows for people that haven't yet setup keys to eventually receive them so long as you trust Keybase's clients and their Proof infrastructure.
[0] https://autocrypt.org/
[1] https://tools.ietf.org/html/rfc7929
The most that can be done at this point is to build a new closed "email v2" which cannot interoperate with any existing client out there, but because of that it will inevitably be dead at launch.
It's not the core email UX that's the problem; it's SMTP email that's the problem.
You're article seems to argue the opposite to me. For example, the following quotes are all related to the email UX:
1. In any group of people exchanging encrypted emails, someone will eventually manage to reply in plaintext, usually with a quoted copy of the entire chain of email attached.
2. Every archived message will eventually leak.
My understanding is that it would be possible to create an alternative app that is compatible with the Signal protocol that would provide a different UX. This alternative UX could, for example, offer the ability to save all messages onto google docs, eliminating the benefits of secure messaging.
Archival is a problem. But you can also imagine something with the UX of Outlook that implements the same advisory-level disappearing messenger feature that modern secure messengers have; in fact, I wouldn't be surprised if you told me Outlook already has that feature (but that it only works for Outlook users).
The problem is the legacy of SMTP. It's not what the UI looks like.
Of course such a client for Signal doesn't exist and is unlikely to become widespread even if it were created. Therefore Signal is more secure. I agree with your conclusion and everything in the article; I disagree only with the claim that it is not a UX problem, and the disagreement is likely that we are drawing the boundaries around what constitutes UX in different places.
Of course these would be very poor design choices for the alternative client, but none-the-less technically possible.
That is, once the recipient has plaintext, we don't know what they're going to do with it. They could read it aloud in a crowded place. They could blab about it to all their friends. They could pass it verbatim to somebody else. Or more innocuously, they could store it in an insecure database as in this commenter's scenario.
Now, if you're using something better than email, the protocol itself won't be the problem and it's less likely (or impossible through the protocol itself) to be an unintentional plaintext transmission, so this fact is pretty moot and not at all a justification of how email clients might behave. Nobody building these systems has to necessarily be concerned about protecting against "social" types of plaintext leaks.
Nobody can do anything about people deliberately subverting the security of their privacy tools. There's nothing deliberate about plaintext replies. The people who do that don't want their messages sent in plaintext.
Also respectfully: If the point of your writeup is to suggest that the signal protocol is better than the SMTP protocol, then I suggest you delete those points from your writeup. If the point of the writeup is that the signal experience is better than the email experience, then I suggest you stop claiming that the signal protocol is better than the SMTP protocol.
Granted the metadata and backlog issuss are themselves serious issues for the format.
It is more a "stop using email even if encrypted" than "stop encrypting email".
This, of course, goes out the window when your threat model is extrajudicial.
Just like SSL/TLS and SSH? They're both specs via RFCs, they both have de facto implementations (openssl and openssh), and they're both used in different contexts (ssh can be used for file transfers, besides remote shells; TLS's applications are very broad like PGP's).
There is a technical sense in which mailers are responsible for mitigating this vulnerability, but it's a vulnerability that can't exist in the first place in a well-designed cryptosystem.
In the context of this post, this is basically a nit; the point the post makes is that even if you replace PGP with something like Age, encrypted email is still too risky to use, and is intrinsically inferior to modern secure messengers. (Encrypted email is not a use case Age is pursuing, and I do like Age).
Is that problem the same as this one? https://github.com/FiloSottile/age/issues/59
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.
-- 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?
Even if that's the case though, you can raise the difficulty by doing it through a phone call.
e.g. https://tools.ietf.org/html/rfc7929
(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.)
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.
I don't, thanks.
Symmetric encryption has ergonomics which are actually easier than asymmetric encryption with the tools we have today.
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).
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...
(I do agree with you)
Many people in the circles I run in have adopted it recently.
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:
At that point, I'd guess you probably wouldn't call it "secure email" though :)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".
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).
LARP here is a link to Google and from the results I can only assume that it expands to "Live Action Role-Playing (Game)". I don't get how that's related. What is "Live Action Role-Playing Security"?
> most people who encrypt emails are LARPing
They're role-playing what?
LARP Security = Pretend Security
LARPing has a connotation of nerds ineffectually playing pretend warrors. Going through an immense amount of effort in the process.
It's true that email as a protocol has inherent insecurities ; and it's also true that dedicated, rich spies are probably able to exploit many of them even with encrypted message bodies.
But most of us are facing the problem of MASS SURVEILLANCE, which statistically is more serious.
So:
1. Stop using spied-upon email servers:
1.1 Drop your Gmail, Yahoo mail, Microsoft etc. mail accounts, in favor of non-US and/or non-huge-corporation mail service providers.
1.2 Try to get your friends and family to drop theirs. Yes, I know this is extremely hard...
1.3 Try to get your workplace / NGOs you volunteer in to drop use of those servers (and also of Google Apps, Office 365, Skype etc. which have strong tie-ins with the email services).
2. Use mail clients which auto-encrypt messages to recipients with known keys - like EnigMail for Thunderbird.
The more of that is normalized, the harder
Also, my suggestions do not make email private, they reduce the exposure to large-scale surveillance and make it more difficult to target individuals. Also, they do not involve "shoehorning" as far as user experience is concerned.
All that you're accomplishing by switching to decentralized servers is publishing the metadata that you claim to be concerned about for free. Before, someone had to serve Google a valid subpoena to find out who you've been talking to. After, you're just broadcasting it publicly across the net in network header logs.
This is not a conspiracy theory - it is public knowledge thanks to the Edward Snowden leaks.
1. Google actively assisted the NSA with data collection, beyond legal obligations (subpoenas etc.)
2. The NSA had a way of legally compelling companies to provide direct access to systems and can do arbitrary processing on company internal data
3. The NSA was snooping in Google's systems without Google's knowledge in 2013, and this hasn't been fixed 7 years later.
As far as I know, the Snowden leaks don't provide any real evidence for (1) or (2), and so are an extraordinary claim without evidence. (3) also seems rather unlikely. Hence the question.
The access isn't as complete as full arbitrary data, but it's also a long way from only responding to known legal warrants and subpoenas.
Most people don't use it this way, but to say it's impossible to secure e-mail is arrogant and not true
Sealed Sender lets them arrange that your recipient knows you sent the message, but they (Signal and its servers) don't - https://signal.org/blog/sealed-sender/ is their blog post about this work.
Somebody connects to Signal, and hands over a message with a recipient. Signal has an ID for the recipient (you correctly observe there's no way around that) but has no idea who sent it, only that whoever it was can prove they're allowed to send this message. They also don't know in a useful sense who the recipient actually is - you can attach a real name, a photo and so on to a profile but only your trusted contacts can decrypt that profile anyway.
It also arranges that by default Sealed Sender only works for sending messages to contacts. If you're a spammer - sending unsolicited messages to people who don't know you - your only way to send messages involves disclosing who you are to Signal, who can choose to rate limit you or block you.
Like the rest of Signal's design the sender's identity is deniable - the recipient knows everything needed to produce a fake message from anyone they communicate with and so they can't use real messages as proof to anybody else.
Because I'm a nerd I actually have the status indicators described in that blog post switched on, so I know that a few weeks later, in the middle of chatting about RDR2 one of my friends suddenly began using Sealed Sender, and other participants in that group joined in over the next few days. To a normal user nothing changed, their privacy improved significantly without them noticing at all.
Anyway, solutions like PGP leak a lot more metadata than just the sender and recipient's identities to every node along the store-and-forward route.
And the very existence of the route also leaks data.
Note that this has nothing to do with key exchange, ie putting it on sd card or whatever, would not change anything about the issue raised above.
There is also about a dozen other issues that the article lists, worth reading for sure.
Does anyone know the background behind this?
When 'tptacek first heard of efail, we were both in the office, he called me over and said "if there was a disastrous GPG bug that fails in way $X, what would it look like" and my first answer was "of course it's that MDCs don't actually work and the packet stream is malleable and something is going to consume unauthenticated plaintext". That's not because I'm some sort of genius: it's because to anyone who has studied the protocol and has a cryptographic background, those flaws are glaring.
That matters because I think it's reasonable to blame a protocol when it is indisputably flawed (there is no debate about MDCs not being a MAC, there is no debate that authenticated encryption is important) and it turns out those flaws all but imply vulns.
RFC 822/2822/5322 e-mail, on top of RFC 5321 SMTP and RFC 3501 IMAP, can't be secure. (And more RFCs I'm probably forgetting).
To most people in the target audience (LARPers, technologist, and others), "email" isn't necessarily that. It's whatever Google/Outlook/... does for them. It isn't a concete set of protocols. But a _type_ of messaging. A particular set of ergonomics.
When framing it from that perspective, people (programmers?) will go "well duh". Then we can move on from the unproductive discussion about semantics and move on to defining new standards, clarifying threat models, and building a real replacement people and companies will adopt. It'll take a lot of coordination and cooperation that can't happen until we've convinced enough people what the real problem is. And as long as we're using vague, subjective terms like "email", I don't think we can.
IMO, better to leave "email" open as a generic term, with the hopes that one of these new messengers (hopefully, Signal) can eventually be standardized and opened to other implementations for adoption inside $bigcorp.
But what do I know?
So appeals to the email userbase aren't especially interesting to me. My concern is that nerds are continuously trying to convince normal people that they should be encrypting email. That's dangerous, and wrong.
Look, your article reads as a general attack on (encrypted) email. Independent of how it is implemented. You mention "PGP" 7 times: 5 times buried in the last paragraph of the intro, 1 time in a random paragraph on key rotation, and 1 time at the very end, as if your entire post was about PGP specifically. Hell, your title doesn't even mention PGP.
You mention "identity" 3 times, "metadata" 5 times, "keys" and "plaintext" 9 times each, "user" 11 times, "messages" 23 times, and the substring "encrypt" a whopping 41 times. IMO that "plaintext" and "PGP" are roughly equal in usage--and that "encrypt" dominates that!--says something far stronger. Here you're here saying "this post is about no PGP" and I'm saying "but you wrote no (encrypted) email".
I'm in agreement about PGP. I'd even go a step further and say you could say any encryption scheme on top of or underneath email would be weak. (Filippo's age? Jason's wireguare? $unicorn? etc.)
Why? Because of the concerns you enumerated in the post that are fundamental to the way the above RFCs work.
---
Think of the numbers and relative scales. x < 0.0001% of email users encrypt using PGP. and LARP. Fine. Attack those users in your blog posts and comments. But y >>> x of emails users play some part in replacing email in the grand scheme of things, with a more secure alternatives.
The expected impact of writing a blog post and convincing ~nobody to quit using PGP is much, much smaller than writing a block post and convincing someone to start consider building, investing in, or supporting others to build that replacement.
And IMO, you're 99% of the way to the latter, and 80% of the way to the former.
That's what I was just saying... Go reread it!
But you also wrote:
> My concern is that nerds are continuously trying to convince normal people that they should be encrypting email. That's dangerous, and wrong.
I'm (just) trying to convince you to broaden the stated impact of your post. You're wanting table scraps from people who won't listen and who have no impact in turn. Ask for something bigger from people who might but have lots of impact when they do. You're nearly there.
I can believe it about Signal protocol, since it’s implemented on Whatsapp and Facebook Messenger. But, if you talk just about Signal proper, are you sure it protected more messages and more people than PGP?
I see this claim fairly often, but no data to back it up
Be conservative in what you do, be liberal in what you accept from others
If you attempt to redefine the term 'email' to be something broader, then you will inevitably be breaking and/or confusing users who expect the current implementation.
The current meaning of the word is simple and useful. Given someone's e-mail address, I can be reasonably sure of a way to send a text that will be received.
A world where 'e-mail' means a family of incompatible (by necessity, if we're enforcing secure communications) implementations would be worse than today.
...or have 30 different walled-garden, not-interoperable, partially-working (for a given ergonomic use case) apps?
Considering that much of present day communication happens on async on email (including important conversations inside and between banks, governments, land-lords and tenants....), I'd say its something that should happen. And if we can convince the right people, it will happen. We'll live for the next ~5 years in a state of hell (just like we do when we upgrade TLS protocols), and then for the majority of people, things will get better.
My 2c.
Users don't care. They'll use whatever is given to them, as long as there is no friction. That's why PGP-encrypted email never took off, except as something that tptacek likes to argue against.
Concretely, we (the security-conscious community) need to convince people (engineers, executives, managers) at Google, Microsoft, Oracle, countless other companies, and a myriad of open source communities that this is something important to build, invest, and collaborate on.
The first part is messaging. Then comes networking, convincing individuals in private. Then comes public collaboration. Proof of concepts, test networks, RFCs, production apps.
But until there's a need and money, this won't happen. And it'll be people arguing past each other on the internet.
In having to choose from about 5 to 6 that I have to now, it would certainly be a nightmare if it fragmented to 3 dozen or so. That would be a major problem.
An interesting parallel could be Apple's introduction to iMessage in the Messages app, to the point where many use the word "text" to actually mean "sending an iMessage".
It's a hard problem. If I tell someone "my email address is samatman@newawesomeemail.com, no, you can't email me from gmail you have to use AwesomeEmailClient", they're going to be confused and nonplussed.
If they can email me from gmail, well, they will. And I have to reply with SMTP, and nothing useful was accomplished.
Try HTTP/HTTPS: we have separate ports, browser preferences, and lots of unified messaging deprecating HTTP.
Suppose we reuse the same format (name@dom). What would a migration plan look like?
Early stages: - DNS record indicating support. - Separate ports. - Reduced spam (because nobody is using it). - No warning messages.
Mid stage: - Lots of dual-stack systems. - Something like HSTS and preloading. - Warning indicating insecure delivery (the client can detect this). - Buy-in from most large corps (Gmail...)
Late stages: - Old, insecure port goes away almost entirely. - Revisions to spec, improvements.
We're still at the tail end of this for HTTPS, and we're building on top of a well-known, supported encryption protocol (TLS, which gets reused elsewhere).
The point is, if Gmail doesn't buy in, you've not made meaningful progress, because they have billions of users alone. And unless they move, most large corps/... won't also move.
That's, in my opinion, why Signal and stuff (while nice, secure, ....), won't replace email.
So how do we get there?
First we need a security protocol with the constraints outlined in the post. - Forward secrecy, - Handles key rotations, - Notifies of device changes potentially. - ...
That's going to take time to design, develop, and standardize. Whether we tie the messaging protocol and format (SMTP/...) tightly to the security protocol (TLS) remains to be seen. It takes time for formal verification too.
Then we need Gmail support. If it is a closed, non-standard protocol (like Signal), it won't be adopted. The RFC process is the only process I know that can influence those types of changes.
And yeah, now? It won't be secure. But we'll have a path from getting to "mostly plaintext" to "mostly secure". And we'll have to live with the fact that it takes time.
If you're not reusing the same address scheme, then yeah. You would have to educate a lot of people about the difference. But if you push that onto the developers, I think that's better. And you can make it mostly transparent to the end user, except at critical times.
It's all about publicity and messaging. We made an explicit, coordinated push to get rid of HTTP. We're still working on it. Think of how many people were/are involved.
We've not had a coordinated push for SMTP. TLS doesn't satisfy anything but a trivial threat and trust model (for secure messaging, when done at the SMTP layer). And that would involve a lot less people if we get it "right" (and it's only a new protocol and not a new app).
If it were up to me (it's not), we'd have a solid technical spec and then try and make this happen. Rather than pushing STARTTLS.
There is kinda a group working on a solution. I don't know what the current status is and what their funding levels are:
https://darkmail.info/
For these purposes, the branding is all wrong. I've not read a recent version of the spec, but there's still commits as of 6 months ago.
Since it's obvious that no on-the-wire compatibility is possible, it's fair to give it a new name for branding/marketing. Sometimes the progress happens that way, the new name becomes fashionable with $politician and $businessperson and using "email" now signals your low status, etc.
BTW, the new-non-email could facilitate fighting spam and attention-fishing through some micro-payments scheme.
These are the ergonomics that people call e-mail.
As far as I know, in pretty much any country where you can send e-mail, you can also send an PGP encrypted e-mail.
So, Signal is not a universal solution.
Fortunately, there's no place in the world where encrypted email is your only option.
We are literally living in an age where the NSA is spoofing cell towers to intercept and save unencrypted (and probably encrypted) traffic to a database that will probably be around as long as the NSA exists. This is naive and everyone should be taking precautions against the kind of power that a true authoritarian government would literally kill for.
I'm also personally insulted to be accused of LARPing for taking steps to preserve my privacy. Even if something like protonmail isn't perfect, assuming it isn't compromised it's orders of magnitude better than outlook, Google, et al who are literally scanning your messages.
Edit: let me clarify my point, because people seem to be misinterpreting what I'm saying. The fact that encrypted email is partially broken does not mean that it doesn't currently reduce the leak surface. If I send 5 emails from a service like protonmail to @outlook.com and 5 emails to @gmail.com, that's two fractured datasets vs sending 10 from a Gmail account where they're all scanned into one database. Locks are trivially picked but that doesn't mean I'm LARPing to everytime I leave my house and lock my doors.
This isn't about having an adversary now, this is about minimizing future risk. A database of personal data is one index or scan away from being used to Target someone. Imagine what the Soviet government could do with information about your purchasing habits, organization membership, political leanings, religious participation. It's happening right now in China.
The fact that you don't have anything nefarious to hide doesn't mean you shouldn't be worried about the existence of such databases. I'm not hiding drug and weapons deals from the NSA, I'm trying to minimize how much information about myself leaks to people who have no business collecting it. All people should be similarly cautious. Unfortunately this isn't the kind of thing that matters to most until it's too late.
How many laws or executive orders or judge rulings do you think it would take before even the U.S. government could trivially abuse such information to target someone? What if you're a whistleblower like Assange? What if you piss off the wrong police officer? You haven't heard of corrupt cops harassing citizens and who stuck their neck out a little too far?
Bad actors exist all over society. It is only rational to minimize the amount of ammunition they may have against you, even if you aren't planning anything nefarious. The problem with this kind of digital surveillance, regardless of whether it is by government or corporation, is that the stored data is permanent and easily harnessed. Let's not even get into the power that such bits and pieces confer to actors with access to even simple ML technology.
I don't understand the reaction that people seem to have toward the desire for maximizing privacy.
Do your house doors not have locks because locks are easy to pick?
Further, wouldn't encrypted email, even in current implementation, be much more effective in keeping secrets if everyone used it? You can do much less with metadata than with email contents, and the fact that leaks of plaintext archives may happen eventually doesn't mean that all archives will be leaked.
The article has a valid point but shaming people by accusing them of larping is IMO irresponsible.
(Note: This is an "everything sucks" type of comment but it's solely based on my opinion and my experiences. I'm not trying to devalue the work of the people who made the respective solutions and I'm not trying to frame this as general truths. I'm sure a lot of what's listed here just comes down to my specific circumstances.)
- Signal: Afaik it requires a smartphone (Android or iOS) and a phone number which are two things I don't wanna be bound to. Additionally, last time I tried it, messages got noticably delayed and I didn't recieve any notifications. I assume this is because I don't have the Google Services Framework installed even though I checked and Signal should (?) work without it.
- WhatsApp: Metadata falls rights into Facebook's hands so no thanks.
- Matrix+Riot: Message delivery was kinda wonky and slow when I tried it. Also it looks incredibly complex which means someone I communicate with will inevitably screw up just as described in the article.
- XMPP+Conversations: This actually looked like it works for a while. What drove me away from it in the end was that file transfer didn't work for some reason in my environment as well as push notifications for some people I talked to. Presumably they ran a version of Android that mandates Firebase Cloud Messaging and Conversations doesn't use that. We did not want to delve into debugging this further.
- other (mostly "decentralized web") solutions: Message delivery was either unreliable, slow or it straight up didn't work. (No hate on the dweb though.)
Email is kinda bad but so is everything else. What kind of solutions do y'all use and why? Is there some "promised land" I've missed?
What about those?
[0]: https://news.ycombinator.com/item?id=6948742
Wire might be a good contender. However, last time I looked at it I wanted to stick with options I could confidently self-host and Wire looks way too complicated on that end. (The recommended way to do it is over Kubernetes which is something I don't wanna touch in production.)
And yeah, Signal isn't exceptionally reliable, I've had messages go missing for hours and even days. I hope it gets better, I'm willing to put up with it for security's sake.
I'm not sure I understand what SMS can do that Signal can't, the difference can't possibly be that Signal requires a phone number, can it? And SMS does nothing to indicate delivery and used to lose my messages all the time back when I relied on it.
Don't use it as much as the others because of network effects, but it works just fine. Requires a user account but no phone number.
The network effect doesn't really concern me. For communication with strangers I'll have to fall back to email anyways since WhatsApp is virtually the only thing that has presence in my area.
But they're going to some lengths to make sure it doesn't stay that way:
https://keybase.io/docs/client/client_architecture
I'm bullish on Keybase, even after the obnoxious Stellar Lumen airdrop fiasco. It seems like they're doing most things right.
I think you need to separate them by requirements. But anyway for all purposes Moxy and tptacek keep touting Wire is way better.
- It's not tired to a phone number, but can be if you want to. Meaning finding connections is just as easy.
- it uses signals encryption
- it's message delivery is better than signals
- It's UI and UX is a million times better than signals. I let my mom use it years ago already. And you looking pretty actually matters to a lot of people.
- The Desktop messaging usecase is properly addressed even for a business setting. Signal feels like a crappy SMS client for desktop on desktop
I have no idea why these two people write the things the way they do, but unfortunately its looking less like a let's get people to use the best solutions and more like smear pieces for everything that is not signal. It's really too bad.
BTW signal as a messaging client when you frequently switch countries is such a horrible citizen on my phone and judging from peoples issues I'm not the only one who has that problem.
- If you have multiple sim cards god knows what you cannot just reply to messages since it will just send from the wrong one.
- If you're in an country with a sim that doesn't send the country code with system messages and it differs from your signal number the country will be detected wrong. Replying might cost you. Everytime I upgrade signal I kinda hope it's fixed, but they might as well just put a wontfix label on it.
- works (with push notifs and instant delivery and file transfer)
- is secure (ideally E2EE that's established and maintained, if I control the server just TLS might suffice although it's probably still safer to push trust to the edge)
- is Free/Open Source all the way through
- is self-hostable in a managable way (I have some but not a lot of knowledge in running and administering services and I'd rather not shoot myself in the foot with something extremely complicated.) Bonus points if there's service offerings I can fall back to.
- isn't bound to phones or phone numbers
SMS doesn't fulfill these requirements, I simply use it because it's the "universe default" in terms of instant messaging. And I assume telcoms are so regulated that they technically could but legally aren't allowed to spy on me. For that I had a glance at my national telcom laws and while I'm not a lawyer it certainly sounded like they aren't allowed to spy on me unless I'm already in legal trouble.
I find it hard to believe that an app that runs in electron and falls for basic web security 101 XSS exploits[1] is a more secure solution than using an encryption layer on top of a federated protocol.
[1] https://news.ycombinator.com/item?id=17050754
For tampering, PGP-signed email is helpful.
For protecting secret communication contents, PGP-encrypted email can be helpful to some degree.
For preventing a surveillance from knowing who you talk to, when, from where and what type of content you likely exchange, email cannot become secure.
I suspect it is the combination of the three the author has in mind.
I'm more optimistic than this blog post allows for. I see email's trajectory over my lifetime and it looks like incremental improvements really do work, they just aren't fast. And I think just as Signal lacks an "Encrypt" button because that's the wrong UX (everything is always encrypted, no need for a button) that's email's future too. You aren't going to install "Really good privacy" and have encrypted email. Just one day perhaps many years from now you'll be debugging a weird problem and you'll discover that without ever noticing it your email is actually encrypted end-to-end and you're not actually sure when then started happening or how.
Anyway, this is it. Its stratigraphy is in the layer above All Your Base but below Leeroy Jenkins. An important, if transitional fossil.
https://www.youtube.com/watch?v=j_ekugPKqFw
That seems to be the vision for Autocrypt [0], although it seems that the current "Level 1" of the technology is "single-click" encryption rather than the ideal of zero clicks.
https://autocrypt.org/
I get the point the author is making re: LARPing, but this kind of attitude and tone is bordering (or, bluntly: is) condescending to anyone who doesn't know as much as you. It's a huge shame because the general discussions surrounding privacy/security are absolutely rampant with paranoid bullshit, and stuff like this just doesn't help. The people you consider to be LARPing might honestly just be new to the idea of security/privacy/encryption/(insert your label here) and would be better served by a tone where you're not talking down to them, especially if you're an established authority.
Personally speaking, I use encrypted email for my personal account - but I'm under no big illusions about it, and at this point it's partly out of laziness as I find moving email providers to be a useless exercise in wasting time. My original use case was my wife and I wanting to send documents back and forth easily, have it encrypted and retained somewhere that's (relatively) easily searchable, and isn't one of the bigger email services. Email is a workflow that goes back decades, and I'm not particularly interested in changing that mental mapping in my brain (a feeling I suspect many would echo).
It's email. It's not encrypted or 100% private if I email my buddy who's using Gmail/etc. It does jack all for my bills, newsletters, and so on. I'm not worried about the metadata not being encrypted because if I needed that level of security, I'd use Signal or some other tool.
You're probably right that it can't be "fixed", but there's also nothing wrong with attempting marginal improvements until an eventual replacement comes along. It remains a convenient "it just fucking works" and until something replaces that, and interoperates with the rest of the way the world actually works, it's probably not changing.
My 2c, at least.
In a world where encrypted email was popular and no reasonable alternatives existed, the equation would be different. But modern secure messengers have lapped PGP and S/MIME a practically uncountable number of times. I don't know what large power of ten the multiple is of messages protected by Signal Protocol compared to PGP, but I do know that it's large. The risk is not that people will naturally gravitate towards encrypted email (which is in practice a nightmare to use), but that well-meaning but poorly-informed technologists will try to talk them into doing that and adding encrypted email to the basket of tools ordinary people use. That can't be allowed to happen.
I also want the analysis to be somewhat bracing for technologists. I'm not making fun of PGP users when I say they're LARPing. I'm describing reality directly and meaningfully. I don't think proponents of encrypted email have really thought through why they're using PGP and S/MIME, and why they're not terrified of metadata collection and the occasional plaintext reply. Their risk profile is not the risk profile of the public at large; when you're LARPing, it doesn't matter if you get hit on the head with the sword.
† Not the term I would choose, but let's stipulate.
If it has katas/forms, if certain moves are proscribed during sparring, or if your teachers have not told you the catch-22 about there being no morally acceptable way to practice genuine kill shots even though they're all that really matters, then you are not preparing for self-defense in a life-and-death struggle.
So, martial arts may be the appropriate metaphor.
Disclaimer: My knowledge here is limited to a few years of kung fu as a kid, a lot of armchair research in the past five years, and an old friend who used to place at multi-state competitions. I'm not an expert so I could be off here.
1) the mugger was going to attack you anyway, and does so every day
2) the "martial arts" was a vicious form of Krav Maga taught to CIA operatives, that was a state secret until a few decades ago
Seems like an unqualified win to me.
This is already happening, which is why I disagree with your messaging: I don't think the way you attack it will fix it, because the people this post will resonate with already (generally) agree with you. But I digress...
I view encrypted email as services like PM/Posteo/whatever paranoia induced flavor of the week fits here. I don't know anybody who tries to use encrypted email straight up - I think the era of running your own mailbox is gone so I don't particularly count it for anything. If you do it yourself, it's a shitshow; if you're on one of those services it "just works".
You can shake the shoulders all you want, but people use email, and people look for the easy win. "Encrypted email" is easier for the average person to latch on to than the UI/UX most secure tooling has right now (a problem even you've noted: https://news.ycombinator.com/item?id=21897173). It's very telling that nothing has dethroned it yet.
Given that, I welcome these marginal improvements while something better is built. These things shouldn't be around in ten years, they're bridges. Email simply has an annoyingly odd usability bar to clear, and nothing is really close to that right now.
If I had to make a dumb analogy, it's like Objective-C and Swift: it's very, very clear that Swift is the future; inherent advantages abound, and much more difficult to shoot yourself in the foot with... but in lieu of Swift, I'd still sooner write Objective-C over straight C, warts and all.
https://imgs.xkcd.com/comics/security.png
If your adversary is going to drop you, your family, neighbours and cat in an acid vat disappearing messages aren't going to save you.
If your threat model is organized crime, signal might be an ok solution, if you have messages set to disappearing faster than you would tell them your password after they start sanding your feet off.
If your model is first world law enforcement I hope you or anyone you care about have never committed any crimes ever because you will have the book thrown at everything you might have done: https://www.goodreads.com/book/show/6611240-three-felonies-a...
If your model is google, then encrypted email is perfectly valid and a wonderful way to use gmail.
In any sane setup, your (and your recipient's) email client will use encrypted connections to and from your respective email servers. Any competent email provider will use MTA-STS, ensuring that no one but the sender, receiver, and respective MTAs can read the message [1]. All this happens for regular unencrypted email, without any effort on the user's part.
So encrypted email purports to drop the ability to allow the MTAs to read the email. But... they don't really do that. Your email providers are required to MITM all of your email, and can trivially modify any plaintext attribute they want to. And anyone who has credentials to your email account can also trivially MITM all incoming email (and may be able to at least social engineer outgoing email, if not MITM as well). This means that pretty much any key discovery mechanism that allows an unencrypted email to initialize or update a public key is defeated [2].
So, encrypted email only provides extra security in those cases where: a) keys are negotiated completely external to email (in which case, why bother with email?), or b) you trust the email provider enough to not try to intercept your messages but not enough to not look at your messages without your permission. Given the BOFH principle (i.e., administrators have no inclination to look at your email because you're boring), that kind of means the second case doesn't really exist as a practical concern. You can improve your security in the second case simply be deleting emails from the server immediately, again not requiring encrypted email.
So... why bother with encrypted email? Unencrypted is secure enough unless you're paranoid, and if you're more than very slightly paranoid, encrypted email isn't secure enough.
[1] This is all happening via TLS, which has gone far, far further than PGP or S/MIME have in actually making "no one can read encrypted text" true. The latter protocols take the stance that "using the cipher.encrypt() is good enough," which has been known to be false for decades.
[2] And DANE-PGP is right out, because your email provider is of course the one publishing your public key.
Because I've been using that method for close to 15 years now?
It's also a counterpoint to one of the OP's points which is that trying to secure email is a dead-end that we should give up on. It may be possible, though very difficult, to transition to secure email. But it would have to be a brand new protocol not tacked-on to the current system. The way that SFTP is the appropriate upgrade path for FTP and not FTPS.
A new e2e protocol that works just like email does would be excellent, but we don't yet have that. Signal &co are chat apps with a different feel and purpose and other than matrix and xmpp not federated, which is a non starter for many entities.
There are some things we could easily give up to get encrypted mail. For example, setting a max delivery time to allow ephemeral keys.
But there are other problems with encrypted messaging, and I'm particularly thinking of spam. How does Signal/WhatsApp manage to keep a lid on it? Would that be possible in a federated system?
If you mean FTPS (which I suspect you do as I actually had to set up something similar at one time), that's FTP over SSL and has nothing to do with SSH.
Your point still stands though: some of the background "FTP a CSV file with a cronjob" crap that goes on in the background would horrify anyone.
PGP and S/MIME do. The latter is used for all sorts of official messages for exactly that reason.
Unauthenticated encryption is rather worthless. Repudiation is a separate matter and threat model.
How so?
Mind you, unauthenticated encryption in terms of signal does not mean that anyone can forge a message, rather that you can't prove to a 3rd party that this was a message sent by the sender rather than forged by you.
b) I'm my own email provider, but I don't trust my server provider (they could read HDD of my server), for example. Or my recipient's provider.
You’re in control of publishing your public key, not the email provider.
I’d be remiss if I didn’t tell you how bad MTA-STS is:
* MTA-STS: compromise for the DNSSEC-challenged
This is only true if you personally fully own the domain and have control of the DNS and other services, which is not the case for the utter majority (at least 99.9%, maybe a few more 9s) of the population. Of course, in that case, you are pretty much the email provider, so not trusting the email provider is a pretty questionable scenario at that point.
> MTA-STS: compromise for the DNSSEC-challenged
Yeah... DNSSEC is a classic example of a solution looking for a problem. Most of your criticism would apply equally well to not using DANE for TLS, and every browser vendor has looked at it and decided against it because it adds no security.
Right now, DANE is the only way to mitigate downgrade attacks with SMTP and TLS connections. Apparently use of DANE for email is growing [1].
DANE hasn’t taken off with browser vendors because of their concern about additional DNS lookups when making TLS connections.
[1]: “Number of DANE-enabled mail domains growing exponentially”—https://www.sidn.nl/en/news-and-blogs/number-of-dane-enabled...
And right from the MTA-STS RFC: https://www.rfc-editor.org/rfc/rfc8461.html#section-2
the mechanism described here instead relies on certification authorities (CAs) and does not require DNSSEC, at a cost of risking malicious downgrades.
So there’s that.
It is not. Unencrypted is environmental pollution that need to be actively prevent until it reach zero use. A favorable future is one where the firewall blocks any unencrypted traffic by default.
Similar, giving third party clear text copies of private information is not secure. It is never going to be secure, and the only half working solution there is the kind of heavy legal regulations and systems that does not exist anywhere yet.
If people want to debate over which end-to-end encryption scheme is best then they can do so as much they want, but in the end the goal here is to stop plain text from continuing harming people.
Email is protected with TLS on all every hop if your provider is competent. My point is that this protection is sufficient for most purposes. Where it is not sufficient, email encryption doesn't actually add the protection you probably wanted (this is the what the original article is detailing).
Project like freedom box could make email encryption obsolete, but thats not because unencryption would be secure enough. It would be because the encryption would be moved away from the individual email and onto the whole server.
Because Gmail does all of those things, and spends more money and effort making sure they do it correctly than you will over your lifetime.
If you have secrets where you believe that, say, a government will extrajudicially lean on Google to access them, theres am equally, or even higher likelihood that you misconfigured something somewhere and leaked your data.
Giving google a plain text copy of everything you say in private communication is not good enough security. Anyone working with information that is covered under privacy laws should be held legal responsible for disclosing it to a third party, regardless if that third party is google or a friend at a bar. If it is a doctor, lawyer or government employee the probability of this is close to 100%. If its a company talking to customers, communicating personal data as defined by the EU between employees, there is only a google breach away from being found out and sued.
The only choice is encryption, with the choice between a encrypted server under the control of the person responsible for keeping the information safe, or encryption per email. Which of those two choices one choose does not matter but giving google a plain text copy and calling it safe is just LARP security.
I should mention that here in Sweden there were recently a large political scandal involving the government using IBM as a third party service provider. Sensitive data got sent over the border and outside the control of the government, and it continued for years as those in charged really wanted to believe that "the cloud" could treated as just as secure as running your own servers. The law said otherwise, and when reality came crashing down things had to change. Convenience does not make it suddenly acceptable to give a third party sensitive information, even if that third party is a large international operator who can't do any wrongs.
Using gmail without encryption in those cases is a security issue and also illegal. A lot of people still use gmail in those cases and google track record in regard to data leaks has meant that few people have been found out. That said it will only take one significant data leak and people will start to dig for all data being sent to google. That day a lot of peoples head will roll.
I would guess without exaggeration that a large enough data leak at gmail would cause a global market crash. There is just too much plain text data containing sensitive information that people would dig into. Not private, not meta, just information which people should not have given to a third party. Google privacy policy does not play a role in that.
Then PGP is irrelevant, you don't email that data around. And even if you are, then you aren't dealing with security, you're dealing with compliance, compliance with legal obligations has nothing to do with, and is often in direct action against, actual security.
> Using gmail without encryption in those cases is a security issue and illegal.
This, almost certainly, isn't true, given that Gmail is a GDPR compliant store. You might need to use enterprise gmail, for the legal requirements, but that's still entirely beside the point. "Use enterprise Gmail" is the solution here, not "fail to use PGP".
Enterprise Gmail is able to operate as a data processor, but there is a lot of fine details in order to stay within the law. It assumes that the company has agreed to the gmail processing terms and gotten permission from their own customer to process the data in such ways. Again here we hope that op security match the fine line between legal and illegal. (If we want a practical example which I know people do, imagine a administrator of a CRM sending a copy of the database to a new hosting provider. Now a copy of the database exist in the sent folder and an other copy at the email provider that the hosting company use. It is very doubtful that GDPR allows that kind of sharing of the private information. If the file get leaked in a data breach there is high probability of a successful lawsuit for mishandling of the information).
Using your own email server or tools that automatically encrypt everything does however prevent those risks.
It sounds like you're talking about encryption at rest, in which case Gmail does that already, more securely than whatever you're doing so the backwards approach to compliance is more effort and less secure in practice.
I wrote a program to do that, but there is also a package in Debian if I recall right that also do it. On the mail server it looks up keys in DNS and if it founds it, automatically encrypts outgoing email.
> talking about encryption at rest, in which case Gmail does that already
Emails at google is not encrypted. Good must have access to the plain text in order to do analytics and search. If google has a data breach it can include every single email gmail has in plain text, and that is a fundamental risk.
> more securely than whatever you're doing
That is kind of impolite to make assumption about my own setup. It is also wrong.
So you're not talking about pgp/e2ee, you're talking about, like, SMIME or something.
> Emails at google is not encrypted.
They're at least as encrypted as they are on your server from what you've told me.
> That is kind of impolite to make assumption about my own setup.
Given that you don't seem to understand the difference between end to end encryption, in transit encryption, and encryption at rest, I'm going to say that no, I'm very confident that you haven't done this correctly.
> It is also wrong.
And that therefore no, gmail and Outlook are both more secure than your email server.
Basic 101 security. In order to calculate risk you take the risk threats minus risk mitigation. The bigger the threat, or the fewer the risk mitigations are, the bigger the risk.
You might have forgotten that in 2010 there was this data leak called cablegate. NSA lost 251,287 diplomatic messages. NSA did store them on an encrypted server, and used transit encryption, and yet the data leaked. A major risk to data security is access, and in that case an administrator with access leaked it.
With my mail server, that administrator is me. One of the larger benefits of personal servers.
When you compare Gmail and my mails server then you include social risk just as much as technical risk. You compare the physical risk, that is servers located in multiple places on the earth. You compare the political risk of a single entity that control 80% of the world email with a private email address used by one person. you compare targeted attacks with passive and optimistic attacks.
Lets put money where out mouths are. Want to bet that google will have a new data leak before I do? Looks like a very lucrative bet to me.
In 2018 Google had a data breach. five million user's data was compromised. In 2018 I had zero data breaches in any of my servers. Zero users data was compromised. I have been running my own server for almost 20 years and not a single bit has been lost.
Have I Been Pwned? has billions of leaked accounts, not a single which belongs to me. What about you?
> So you're not talking about pgp/e2ee, you're talking about, like, SMIME or something.
No. There are RFC for email security written in this century. The adaption of putting pgp keys in dns is not great however which is why personal email servers is currently better, but both solution works fine either way as long both side of the conversation does it.
Ah I see, so you aren't actually worried about security, you're worried about privacy. Which We've been over when I said:
> Privacy is not security.
You also are ignoring a whole host of other risks, like data loss (your one server breaks, oops there goes your all of your email, etc.)
> Lets put money where out mouths are. Want to bet that google will have a new data leak before I do? Looks like a very lucrative bet to me.
Sure, I'll bet you $10,000 that my email will not be leaked before yours. Here's what we'll do, I'll tell you my email address, and you tell me yours. Mine is @gmail. Yours is hosted on your server. I'll then turn around and spend $8000 on a pen-test of your server, they'll exfiltrate data, and I'll win the bet and be up an easy $2,000.
> In 2018 Google had a data breach
Pause, hold on. No. In 2018, Google announced that there was a vulnerability that could allow semi-public information to be shared more widely than intended (literally it was things like name and phone number that you put on your G+ profile being shared with a wider than intended audience).
There was no evidence that this vulnerability had been used, and Google's own employees detected it.
> In 2018 I had zero data breaches in any of my servers
that you detected. Here, Google has a better track record than you: they are actively monitoring and red-teaming their own servers and systems to detect vulnerabilities. Do you?
So I'll put it bluntly one more time: you are putting your clients data at more risk by administrating your own mailserver than you would be if you let Google or MS do it for you. You can try to come up with all the counterarguments you want, but they are, as this article puts, security LARPing, not actual security best practices.
In the end, if you have your email leaked while I do not then that is what matters. Results. I have had zero leaked accounts. Most people have stuff that been leaked, and since you refused to answer, I assume you are listed in Have I Been Pwned?. You trusted someone to be secure and they were not. That was your choice, and it was the wrong one.
If you break the law however, which is what happens if a pen test a system without permission, then it doesn't really matter if you hack or use rubber hose tactics. Breaking the law is breaking the law. The police don't look kindly to bets under those situations.
I will also say the same thing I wrote to those two pen testers that tested our system. If you find any vulnerability I will happy help write the CVE report. What I did not tell them but will mention here is that I also happy take part in getting those bug hunting reward money that zero days exploits usually rewards. If you have for example a working exploit against current stable release of latest SSH then I am sure we can turn that in somewhere for a pretty good amount of money.
https://en.wikipedia.org/wiki/Room_641A
Again, if your counter party is an idiot nothing will save you.
PGP requires that you not only not be careless, but be near-perfect, and that every counterparty does the same. Good protocols prevent you from making mistakes that spew your plaintexts everywhere.
In other words, I want a protocol that doesn't necessarily protect me from idiots, but does protect me from humans who occasionally act imperfectly.
On the other hand, UA (for any protocl) which will not allow copy'n'paste from is crappy by definition and nobody could stop your recipient to copy'n'paste plain text from your message. Ultimately, it is THEIR message as much as YOUR message!
On the side note, I think that GMail is worst thing that has happened both to the web and to e-mail.
A secure protocol would, for example, not mix plaintext and encyrpted text messages, but would ensure that all messages were always encrypted. This way a we'll designed user agent couldn't accidentally mix cypher and plaintext messages.
I'm not arguing that UAs should do user hostile things in the name of security, which is the straw man you're arguing against. Nor did I mention anything webmail specific.
I'm saying that a security protocol shouldn't have, in practice, fail open attributes that user agents have to put warnings up about. A good protocol should allow the UA to entirely hide those dangers.
This is abundantly clear if you try to use any pgp mail client vs any signal protocol client. The protocol makes it easier for UAs to be both more secure and more user friendly.
Schemes like "everyone has great opsec".
You mean mailvelope[1]? That's a straight up plugin/extension. It gets installed once and is as secure as whatever is used to secure extensions on a particular browser.
[1] https://www.mailvelope.com/
The stupid thing is that I know this is not what you actually believe. You say it in the first sentence of the second paragraph of the comment I'm responding to. If this is the tool you have, then it's a tool you can use. If you use it properly and understand the limitations, then it is fine. It's more than fine. It does what it needs to do!
I get that it's extremely easy not to understand how to do things. I get that it's extremely easy not to understand the limitations. I get that it's extremely important to send the message that unless you actually, truly know what you are doing, then probably you should not be using email and OpenPGP to encrypt messages. And in fact, if you have the chance to use something better, you really, really shuold. I get all that stuff. But it is just wrong to imply that you can't send information securely using OpenPGP and email. I mean, it's infuriatingly insulting to be told by a security expert (which I readily and without reservation admit you are) that I'm just playing when I know said expert knows they are exaggerating to push their agenda.
I can even show considerable sympathy for this agenda. I think you do a wonderful job of explaining problems and showing where there are better ways of doing things. You are doing good work! But, stop with the insults, please. It's beneath you. It pisses off people like me that would love to support your cause but are so pissed off with your attitude that I can't bring myself to do so. You are hurting yourself and you are hurting your cause with this line of nonsense.
People should stop using encrypted email.
Not every application is your application. Not every fight is your fight. If you absolutely must insult someone, target it and be specific. But, better yet, get your message across without insulting people. It will be much, much better.
I didn't see your original message but I'm sure it was well-intentioned and wrong. I am wrong often too. Just not this time.
Taking back an HN post you think will be taken as uncivil is a strong move. Respect for taking the community seriously. There's nothing personal in my criticism of encrypted email; it's the technology I hate, not the people behind it.
https://github.com/signalapp/libsignal-protocol-c
I think author is advocating for all of communications to be encrypted and it cant be email because its just bad. People should stop advocating for it.
LARP is a popular free time activity with nerds here in Germany. And people will fawn over kit and/or spend money on extravagant but useless equipment to earn social status inside the community.
So I thought that calling people LARPing was actually quite clever, because the reason why I would roll out buggy encrypted email would be the same as for why I'd walk around in a cow leather robe in a forest shouting like a madman. I have done both, btw.
And just like nobody would complain about me accidentally breaking character during LARP, nobody would complain if I accidentally break the encryption by replying the wrong way.
So as someone enjoying LARP and dabbling with encrypted emails, I didn't feel offended by his comparison.
You're great! Loved this.
I'm still looking for a solution for the situation when I'm trying to communicate without revealing my identity to the person I'm talking with. Signal's reliance on phone numbers means I'd need to get a bunch of burner phones or something, which is beyond what I'm willing to do: I'm not talking about an ultra-high-risk situation, just I'd rather not announce who I am when I'm interacting with people I don't know that well.
What do you think is the most promising tool for this sort of communication? I've been hearing about Riot/Matrix; do you think that's a good option for people to use?
Another concern I have with the proposed replacments is many (Signal, Keybase, etc.) depend on a single centralized service.
> I'm not talking about an ultra-high-risk situation, just I'd rather not announce who I am when I'm interacting with people I don't know that well.
In that case, yes, with some caveats.
Be mindful of your list of Matrix devices because that is something all participants can see. Otherwise, Matrix will allow you preserve basic anonymity with respect to the other participants (but not with respect to the server) with solid encryption.
Also bear in mind that Matrix is built on the premise of storing all messages server-side indefinitely by default (in end-to-end encrypted form and with regular key rotation so forward secrecy is preserved).
Of course, forward secrecy does not help if the participants retain all keys indefinitely and subsequently leak them. I think disappearing messages are in the works.
This exists. In the past, it took the form of an "anon.penet.fi" email address. This was a very simple, useful service[1] that many people used to great advantage.
In modern times, you can see this very same concept used at craigslist wherein CL maps your email address to a random craigslist email address, allowing you and another party to have painless email back-and-forth without leaking identity.
Now that I am thinking about it, you could set up a simple SMS remailer with codes that would allow the same thing to happen.
None of this addresses secure comms, but that's not the question you asked ...
[1] A "remailer".
CL implementation is flawed and only gives perception of privacy. I forget the header/tech name for it, but if you hit reply and your email account is set to “First Last <email@domain.com>” it will pass along that entire string to the recipient in the body of the email. The obfuscation is only in the actual email address the message goes through
The condescension I see is in calling out "technologists." I've never heard that before. Just looking at the word it sounds like it means a person who works with modern technology. Wouldn't that encompass the majority of Hacker News readers? But by context you don't seem to have a favorable opinion of the group. What makes someone a technologist to you? Do you include yourself and if not why not? What justification is there for you to generalize people in such an unflattering way?
Oh wait, https://en.wikipedia.org/wiki/Signal_Protocol#Metadata metadata collection?
Pgp: you can see the title, sender, and recipient of every message.
And yet, you catch more flies with honey than vinegar. Or, in other words (although this is an exaggeration) pulling a Linus to get your point across is counterproductive. The hostility radiating from article will turn off a lot of people who otherwise might benefit from considering it.
PGP considered harmful for being a clusterfuck.
Code signing is probably the only use case left for it.
Edit: nope a quick Google search finds specialized tools. They can't be harder to use or screw up than PGP, so automatically better.
Etymologically it probably emerged in the infamous *chan-culture, and is in active use there in the sense of ‘pretend play’ or ‘on-line role-playing’. It can be used to signal, in a derogatory way, that you feel that the other is spinning a yarn or indulging in a fantasy, without declaring the fictive nature of their comments, in order to provoke responses and bait others into participating.
I wouldn't use this word in polite conversation, unless you are actually talking about live action role-playing.
If someone is running TailsOS/Whonix/Qubes as their daily driver OS, and only browses from TOR, connected through a VPN/cellphone tether/coffee shop WiFi, with full hard-drive encryption using VeraCrypt+hidden partitions with a killswitch to zero out the harddrive if a certain password is entered, and runs their laptop with no battery, with a CoreBoot/LibreBoot flashed BIOS -- then they are taking this shit way too seriously and will be chided as a LARPer.
Yes yes, I understand security is important -- I used to be a vulnerability researcher who transitioned to "red teaming" for a government agency -- but the above is taking things too far, especially if you're just a layman that barely makes it on anybody's radar.
That's LARPing. It's like when a script kiddie buys a DDoS service, and calls themself a "hacker," for overloading a server (AnonSec/Anonymous I'm looking at you, morons). It's roleplaying, it's childish, and it will get ridiculed for its self-aggrandizing.
2. I don't know why, but everytime someone mentions that they're offended or miffed about something someone else said, especially on the internet, I have a very hard time taking them seriously.
I believe it's because I grew up on hearty banter, and anyone that couldn't hang was, in my eyes, a chode. No disrespect, but I wanted to share that insight with you. Maybe it'll come in-handy somewhere down the line.
1. To the outside world, a LARPer might be indistinguishable from someone that actually needs perfect opsec. Maybe that LARPer in the coffee shop is Ross Ulbricht.
2. If one day you actually need real encryption, it will help if you've LARPed in the past.
For the meaning behind the choice from the author see this comment: https://news.ycombinator.com/item?id=22372065
Cargo-culting implies you recally do care about the outcome, but you don't know how to get it, and the technique you have is copied poorly from someone else.
To extend things, it's true that if you are about to go in a duel to the death and you are preparing by studying how LARPers sword-fight, you may be Cargo-culting during the duel.
It's pointing out that the emperor is wearing no clothes: that they're ridiculous. It may not help someone already too deep to dig themselves out, but it will probably stop at least a few people from getting on the wagon at all; no one wants to look like a fool.
Privacy is a human right, but I think it is a step too far once you ridicule people just because they don't value it as much as you do. There is nothing wrong with being "ridiculous". Who are you to judge who counts as a fool?
"The Emperor's New Clothes" (Danish: Kejserens nye klæder) is a short tale written by Danish author Hans Christian Andersen, about two weavers who promise an emperor a new suit of clothes that they say is invisible to those who are unfit for their positions, stupid, or incompetent – while in reality, they make no clothes at all, making everyone believe the clothes are invisible to them. When the emperor parades before his subjects in his new "clothes", no one dares to say that they do not see any suit of clothes on him for fear that they will be seen as stupid. Finally a child cries out, "But he isn't wearing anything at all!" The tale has been translated into over 100 languages.[1]
The point isn't...whatever you're talking about, it's that the people do value it a lot, they're just shooting themselves in the foot.
You need to be strategic about it. I've met someone with anti-vax beliefs, and pointing out her errors without mocking her worked wonders. I believe she actually changed her mind.
Strategic is mocking them to prevent their stupid ideas from spreading. (Public shaming creates a resistance at scale.)
Tactical is breaking from the general strategy to help at an atomic unit (i.e. one person).
For my services that use automated emails, I only send plaintext emails and use shortlinks. No sense in wasting time trying to make an email look good on every provider and hope it's encrypted or worry about which ones it will be blocked from because they don't support encrypted.
It should be used as a notification mechanism nowadays. But we do need a better universal platform - maybe that's webpages...
I think only regulatory action could be a way out of the messenger mess (which potentially leak even more metadata). I don't want to be forced into closed telecom ecosystems by my (real life) social network. The problem with potential message routing regulation will be that governments mandate weak crypto for law enforcement.
So I guess email is a dinosaur worth preserving. Even with security after design. delta.chat comes close to an deal world IMHO if you ignore the problem with metadata. Maybe it could integrate sth like mixes to make email a bit harder to monitor.
I don't think we'll see homing pigeons make a comeback, but using autonomous vehicle couriers for analog/digital communications (drones, but more likely sdc's) and sacrificing the convenience of real-time communications for 100% integrity is not beyond the scope of reason or wants. If a message (or payload) is intercepted, it's physically impeded and much easier to track/detect. The number of layers of security to lockdown or destroy the contents is also at the sender/receivers discretion.
Depending on how cumbersome they choose to make 8k videos, VR worlds and/or new fangled AI/ML datasets for personal/business use, we're limited to 6720 GB transfers per day over 1GB lines, so data outgrowing the Internets transfer speeds is a plausible scenario that may facilitate a use case for local and long-haul direct autonomous data couriers that will blend in with the other autonomous delivery/pickup traffic.
I understand that this article is for the secure human-to-human messaging use case. That's fine; I have no argument with this. But outside that context, it makes no sense, yet generic claims like "encrypted email is bad" are being made. This is too broad.
I understand that the majority of perceived demand* for encryption may be for secure messaging. On that basis, maybe you think it's OK to disparage encrypted email because a win in getting universal secure personal messaging with the modern desired properties would be worth the cost. But isn't this a strawman? Who exactly is a proponent of encrypted email for secure personal messaging anyway? Who is using PGP for personal encrypted communications today who is being harmed?
* Because most people don't care; it's only a minority of advocates who, rightly or wrongly, believe that everyone should.
What threat model is this?!
(In all honesty, I don't believe you. I presume you're paying those invoices, in which case whatever attacker you have in mind can just follow the money and monitor the metadata to learn everything they need to know about those invoices. Or, more likely, your threat model is "nobody's seriously gonna snoop on my payments to this supplier; I just think it's fun to play with PGP.")
One point. The encrypted systems are many and not inter-operable. That's a problem for me and many others.
For me this is a good compromise and a great alternative to messengers like Whatsapp and Telegram. This is a first step towards decentralization while relying on the existing email infrastructure.
Although only when used properly - again, there's no point in relying on Delta Chat if your correspondent is going to forward your messages to people on gmail.
but smtp will know anyway.
i think, this is a general issue with "who is messaging whom" - also signal, whatsapp, whatever have to deliver the message and cannot know this afaik when these delivery data are end-to-end-encrypted. so this is not only an email problem.
but with email, at least, there is no "global" server that sees everyhing (no, also not gmail outside us :) and can draw a huge social graph.
[0]: https://github.com/signalapp/Signal-iOS
[1]: https://github.com/signalapp/Signal-Desktop
[2]: https://github.com/signalapp/Signal-Server
Yes, you can host your own _Signal server and have your own singed apps but it will have to be your own _Signal network, not Moxie/Signal Foundation's Signal. Search around. Here's one - https://gist.github.com/aqnouch/9a371af0614f4fe706a951c2b976....
Some context:
https://github.com/signalapp/Signal-Android/issues/282#issue...
https://github.com/signalapp/Signal-Android/issues/127#issue...
https://github.com/LibreSignal/LibreSignal/issues/37#issueco...
I don't think that's quite true. You might[0] be discouraged from running your own self-built binaries, but given that Signal Android has reproducible builds[1], I don't think that there's any actual technical barrier. The context of your links is about having (unofficial) third-party packages for Signal, not about somebody building the binary for their own use, and since these are obviously two different things, from a social perspective, I don't think that the Signal foundation would complain much about the latter (given reproducible builds and the fact that you wouldn't be distributing the binaries, they probably wouldn't even know about it).
For Signal-iOS, it seems that you won't get push-notifications if you build by yourself.[2]
[0] I'm not 100 % convinced that "We would not recommend that anyone use an unofficial binary build" was meant to refer to building for yourself, by yourself.
[1] https://github.com/signalapp/Signal-Android/blob/master/Repr...
[2] https://github.com/signalapp/Signal-iOS/blob/master/BUILDING...
This is a pretty typical example from the article of the sort of important sounding but ultimately bogus argument presented in such articles:
>So, for example, it recently turned out to be possible for eavesdroppers to decrypt messages without a key, simply by tampering with encrypted messages.
By failing to actually specify the actual attack the writer hopes to prevent a rebuttal. I am pretty sure they are talking about EFAIL. EFAIL was itself a weird slander of the idea of encrypted email but ultimately did not show any weakness of either PGP or S/MIME. It was instead a cautionary tale about the use of HTML for email.
The article attempts to promote Signal as superior to PGP email. That is unlikely as Signal initially trusts the phone system for identity. It is also quite a lot more complex than PGP so the odds of an exploit are not in Signal's favour.
Indeed, which makes it ironic that ProtonMail (a webmail provider) was not affected by the vulnerability:
https://protonmail.com/blog/pgp-efail-statement/
If an issue with handling HTML is grounds for abandoning PGP, then it should also be grounds for abandoning Signal:
https://news.ycombinator.com/item?id=17050754
Signal protocol doesn't have the same lack of integrity checking.
If a protocol compliant impl is vulnerable, and the fix is to update the protocol, the protocol is broken.
Yes without html you couldn't build this gadget, but we don't blame machine code for making gadgets possible, we blame insecure c for having buffer overflows.
> However, we found that several clients only gave a warning to the user for invalid MDCs, but still displayed the modified plaintext. This allowed the CFB gadget attack despite the MDC
No, the problem was that clients would render a plaintext known to have been tampered with. This was exacerbated by a zero click gadget, but would still have been an issue if images weren't loaded and a malicious link was clicked.
You're right that Gpg wasn't shown to be broken, but pgp was. (This is the CBC attack, not the direct attacks on clients which are just client bugs, which themselves aren't direct evidence that a protocol is broken)
GPG2 is the ubiquitous implementation. You mean the OpenPGP standard was broken? I don't understand what you mean.
What you said there can't be stressed enough. Despite that almost no email client in the past decades defaults to allowing active or remote content. But because you could turn all that on with some clients... it somehow means PGP and S/MIME were impossibly insecure.
"Weird" is a good word to describe things.
Also, one of the Efail exploits (the CDC gadget) was a cryptographic vulnerability. The fact you could manipulate the ciphertext to inject HTML tags such that GPG wouldn't scream bloody murder (because the MDC wasn't required and had very odd semantics, where GPG would output data to the caller before it had been authenticated and clients showed it as a warning and still rendered the HTML exploit) was definitely at its core a cryptographic bug.
All of this was explained in significant detail in the CCC talk about Efail[1].
[1]: https://media.ccc.de/v/35c3-9463-attacking_end-to-end_email_...