Poor Johnny still won't encrypt

Summary

This title is an obvious nod toTo 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 model.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 M...