Commentary on “Stop Using Encrypted Email”

“Email is unsafe”

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:

• STARTTLS (2002) is intended to protect emails from being intercepted while being sent between mail servers. Unfortunately it is not considered a strong security layer because it doesn’t protect against man-in-the-middle[1] and is not widely adopted among smaller mail service operators[2].
• Message-level encryption such as PGP (1991) and S/MIME (2002) is intended to (a) authenticate the sender of emails, and (b) protect the content of emails from interception by any third party (including the mail services). This is what people mean when they say “encrypted email”. Both PGP and S/MIME have design flaws that make them ineffective against interception[3], and these flaws cannot be plausibly fixed.

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 […] is performative”

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[4], to have a GnuPG key. In bygone times conference and meetups would host “key-signing parties”, where people brought their laptops and photo IDs and solemnly cross-signed each others’ keys. Hex-formatted key fingerprints were inspected. I swear I am not making this up.

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.

“PGP is a deeply broken system”

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[5] packet-oriented record format with a small list of supported ciphers.

The problems with PGP are not limited to the protocol, but extend to the usability and security properties of related projects such as GnuPG[6] and the SKS keyserver network[7]. If starting from scratch, no contemporary security engineer would design something as slapdash as PGP.

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.

“All mainstream email software expects plaintext”

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[8]), which is why PGP should be avoided.

“Metadata is as important as content, and email leaks it”

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:

• Adversary: a ten-year-old child
• Goal: find out what present they’re getting for Christmas
• Capability: physical access to parent’s locked iPhone

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.

Alternatively:

• Adversary: the United States federal government
• Goal: obtain evidence of contact between Jane Doe and John Smith
• Capability: can demand a full copy of Jane’s email account pursuant to an authorized search warrant

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[9]. But they don’t have the power to compel Jane or John to decrypt their side of the thread? Outside of a novel, this particular combination of capabilities and limitations is rare.

“Stop using encrypted email”

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.