This title is an obvious nod to
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 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?
... continue reading