Poor Johnny still won't encrypt

The state of email encryption

This title is an obvious nod to

• The 1999 article Why Johnny Can’t Encrypt, and

• The 2006 article Why Johnny Still Can’t Encrypt: Evaluating the Usability of Email Encryption Software.

To encrypt email in 1998 you’d run GnuPG from a terminal, importing the recipient’s public key into your local keyring then copying your email text into a file then encrypting the file for that public key: gpg -e -r alice file. Finally you’d copy the encrypted message into your email client and send it out.

In 2025, it’s pretty much the same. In some respects, it’s worse:

• It feels like fewer people care about email encryption today than they did in 2010.

• Web-based email has become dominant, and that shift works against PGP usage. Desktop clients at least offered some support (native in Thunderbird, third-party extensions for Outlook and Apple Mail.) Most webmail services, by contrast, offer no native PGP support at all. Proton is a notable exception.

“But there’s S/MIME!”

S/MIME (RFC 2311) was standardized around the same time as OpenPGP (RFC 2440), in 1998. PGP’s trust model is the “web of trust,” though often TOFU in practice, while S/MIME’s model is the more organization-friendly hierarchical PKI.

As a result, S/MIME is more common than PGP in enterprise email. It’s also better supported by email clients. Even Gmail for organizations supports S/MIME. You need a basic PKI and to generate key pairs, and then to distribute them manually:

What about Microsoft/Azure, the dominant enterprise stack? You’d expect managed endpoints to support key generation and distribution across an organization—centrally administered, cross-platform. In practice, Microsoft makes this harder than it should be. The process remains largely manual, poorly documented, and needlessly tedious.

Why nobody seems to care?

Auditors obsess over encryption at rest—from laptop FDE to databases’ security theaterish at-rest encryption—and over encryption in transit, usually meaning TLS. But they seldom bring up email encryption and send confidential email text and attachments like there’s no tomorrow.

The reality is blunt: most email traffic doesn’t enforce encryption, as MTA-STS adoption remains very low. Opportunistic encryption (STARTTLS) is more common, but obviously vulnerable to downgrade attacks.

There are even fewer incentives to fix this today, now that we have session-based messaging systems—mostly Signal, but also Olvid, Threema, and WhatsApp. Their statefulness enables protocols that, unlike PGP or S/MIME, protect against replays and provide forward secrecy (and the less critical “post-compromise security”).

Another factor is simple displacement. Organizations use email far less than in 2005. Most internal written communication now happens over Slack or Teams. These systems are not encrypted save for the client–server link, with the server often running in third-party infrastructure

So expect less and less PGP and S/MIME and, if we’re lucky, a bit more MTA-STS.

Featured image: pirate Johnny Depp.