Signal is a reasonable choice for sending encrypted messages.
Email is unsafe and cannot be made safe. The tools we have today to encrypt email are badly flawed. Even if those flaws were fixed, email would remain unsafe. Its problems cannot plausibly be mitigated. Avoid encrypted email.
The basic problem of email (meaning specifically SMTP) is that it was never designed to be secure. The address must be sent in a form readable by the recipient’s mail server, and auxiliary data like the subject comes along for the ride because that’s just how the wire protocol works.
There have been two major security retrofits added to SMTP since the original RFC 821 was published in 1982:
Even if these two security-oriented additions worked as intended – if emails were protected in transit, and message bodies end-to-end – the design of SMTP still makes email unsuitable for secure communication. More on this below.
Most email encryption on the Internet is performative, done as a status signal or show of solidarity. […] It doesn’t matter whether or not these emails are safe, which is why they’re encrypted so shoddily.
It is common, among geeks of a certain age
In retrospect none of it was real, or rather, none of it mattered. We never put much thought into the actual cryptography – the few GPG’d emails I sent could have been unpadded CBC for all I know. The point of signing your coworker’s GnuPG key was not to establish a secure comms channel. It was all about the ceremony: the grown-up version of children passing notes in Pig Latin.
The least interesting problems with encrypted email have to do with PGP. PGP is a deeply broken system. It was designed in the 1990s, and in the 20 years since it became popular, cryptography has advanced in ways that PGP has not kept up with.
The early ‘90s were not good years for computer security. A lot of primitives and protocols designed back then turned out to be either too complex (ASN.1) or not sophisticated enough (MD5, SSL v2/v3). PGP managed to be both at once, combining a challenging
The problems with PGP are not limited to the protocol, but extend to the usability and security properties of related projects such as GnuPG
So, for example, it recently turned out to be possible for eavesdroppers to decrypt messages without a key, simply by tampering with encrypted messages.
This is referencing the EFAIL attack, in which most mail clients can be convinced to send the entire contents of an encrypted message to an arbitrary remote server.
The foundations of electronic mail are plaintext. All mainstream email software expects plaintext. In meaningful ways, the Internet email system is simply designed not to be encrypted.
The clearest example of this problem is something every user of encrypted email has seen: the inevitable unencrypted reply. 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.
Some people reading this might have GPG keys; a smaller set might even have exchanged GPG-encrypted emails with a contact. If you were to send an encrypted email, and receive a reply in plaintext that quoted your plaintext message, would you be upset?
If the answer is “probably not”, then what security value is GPG providing?
The strength of a security system is not only in the low-level parts, the ciphers and key sizes and so on, but in how it interacts with humans and guides them towards safety. A tool designed to send un-interceptable messages should make it difficult to accidentally leak the entire conversation. This is not true of PGP (as typically used
Leave aside the fact that the most popular email encryption tool doesn’t even encrypt subject lines, which are message content, not metadata.
The email “envelope” that includes the sender, the recipient, and timestamps – is unencrypted and always will be. Court cases (and lists of arrest targets) have been won or lost on little more than this. Internet email creates a durable log of metadata, one that every serious adversary is already skilled at accessing.
In security circles there is often talk of an “adversary”, which summarizes what the system is supposed to protect against. The adversary of a child-proof medicine bottle is a curious toddler. The adversary of a journalist reporting on organized crime is the criminal organization. The adversary of a group of anti-government rebels is the local government’s law enforcement agency. In each case the identity, capabilities, and goals of the adversary are used to decide what the system must protect against.
A typical “threat modeling” exercise might start off with something like this:
In this case, organizing the purchase of a Christmas present over encrypted email is probably not worth the effort. A passcode on the phone, or at most some basic precautions (e.g. not putting the word ‘Christmas’ in the planning emails) is probably sufficient.
In this case the use of encrypted email isn’t sufficient. The presence of emails between Jane and John is satisfies the adversary’s goal, and they can always come back for round two by demanding (from Jane and/or Joe) the emails be decrypted. The best option here is a messaging system with encrypted metadata, forward secrecy, and an enforced retention period – none of which is a feature of encrypted email.
What adversary is PGP protecting against? It’s not clear. The adversary has access to the ciphertext (otherwise PGP never enters the picture), which implies some significant real-world power – to wiretap an ISP, or compromise one of the mail providers
There are reasons people use and like email. We use email, too! It’s incredibly convenient. You can often guess people’s email addresses and communicate with them without ever being introduced. Every computing platform in the world supports it. Nobody needs to install anything new, or learn how to use a new system. Email is not going away.
Stop using encrypted email.
It’s important to remember that this advice to avoid encrypted email is specifically about avoiding encrypted email. It’s not a problem to send ordinary, non-sensitive messages over email. Some messages will get logged forever by some shadowy agency. Some will get STARTTLS, as a treat. So long as messages needing secure handling are sent only over secured channels, it’s fine to send the rest over email or iMessage or LINE or WeChat or whatever.
Just please don’t PGP it.
See The sad state of SMTP encryption and Enforced STARTTLS for SMTP. The implementation of
MX DNS records reduces STARTTLS to more of a public hygiene benefit than a strong security layer.
Google’s transparency report summarizes adoption of email encryption in transit.
As far as I know they’re still OK for authentication of plain-text unencrypted messages, if for some reason this is your use case.
I will admit I have a GPG key, and it’s published to the keyservers. I used to have its public part on a page of this website, in case someone needed to contact me on urgent Snow Crash business. I have never attended a key-signing party, but there was a time when I would have if the opportunity arose.
Parsers are a rich source of security problems. When designing a serizalization format, especially for a security-critical protocol, “challenging” is a synonym for “bad”.
What’s the matter with PGP?
My own personal workflow for GPG was command-line based; I would copy ciphertext out of my mail client into a terminal, decrypt it, encrypt the response, and the copy it back. This workflow is atypical; most users of GPG interact with it via a mail client plugin such as Enigmail, which transparently decrypts messages in the mail client.
Another difference between 1990 and 2020 is that mail providers – hosted services in general, really – are more professionalized now. Apple, Google, and Microsoft have security departments larger than the entire headcount of a mid-90s ISP. For someone who is worried about the security of their mail provider, the best solution is to switch to one of these large and well-regarded options.