If you think about emails as if they’re anything but the digital equivalent of a postcard–that is to say, they provide zero confidentiality–then someone lied to you and I’m sorry you had to find out from a furry blog that sometimes talks about applied cryptography.
At the end of 2025, at the 39th Chaos Communications Congress in Hamburg, Germany, a team of security researchers posted some devastating vulnerabilities in PGP software (with a focus on GnuPG), and published them at gpg.fail.
Note: They also discussed a minisign vulnerability and another attacking age’s plugin system, but these were much less severe than some of the GnuPG vulns.
This disclosure reignited message board debates about GnuPG, OpenPGP, and related topics. I’m not going to reiterate the many problems with PGP or what you should use instead.
Instead, I want to explain why cryptographers and security engineers that work on cryptography have largely abandoned any efforts to make “encrypted email” happen.
Email is not simple. Even before you get into protocol discussions, email is actually several things bundled into one software package:
Cc: and Bcc: fields.The way society uses email (at least in the United States, anyway) has conditioned everyone to treat email as more reliable than it actually is.
So it’s really no wonder that email is how most medical, legal, and financial workers operate in their day-to-day (assuming they aren’t using certified mail or fax machines).
But then the security nerds point out that:
…it’s tempting to rush to PGP or S/MIME to reclaim a bit of privacy for your communications.
If that doesn’t make you feel all warm and fuzzy, remember that many industries still use FTP to transfer encrypted ZIP files back and forth in 2026.
Then, when even more security nerds point out how bad PGP and S/MIME are (EFAIL, gpg.fail, Why Johnny Can’ Encrypt, etc.), everyone gets frustrated.
Let’s set aside all the security vulnerabilities for a moment and explore an extremely common failure mode.
Suppose you send some of your friends an encrypted email.
First, your friends need to have their own private/public key pairs and exchange public keys with each other.
In PGP land, this sometimes meant setting up a “key signing party” to attest to each other’s identities, so that others could see these vouches from the “Web of Trust”. (This was a really big thing right after the Snowden leaks.)
But for simplicity, let’s ignore PGP entirely.
Let’s say you do all this, and successfully begin sending encrypted emails. Hooray!
How long until one of them, in a hurry, hits “Reply All” without encrypting first?
This exact kind of failure happens all the time with encrypted email solutions.
And since email responses, by default, quote the thing they’re replying to, this kind of mistake can leak the entire message chain leading up to the mistake too.
One of the main reasons I recommend Signal is because there is no plaintext mode to accidentally use.
Sure, you can go out of your way to bypass the encryption if you want to. No one disputes that.
But what you cannot do with Signal is accidentally emit plaintext to the Internet by using the Reply feature.
With encrypted emails, the “accidentally disclose a bunch of plaintext” footgun is in the hot path of the user experience.
These are very different propositions of misuse and anyone that conflates them is being dishonest because they want to mislead you.
One of the limitations of encrypting the message body of emails is that there is still a ton of metadata that gets transmitted in the clear (i.e., often without even transport-layer encryption).
If nothing else, a passive adversary learns the following:
To: and Cc: fields (and, practically, always the Bcc: field)But the subject line is the most critical. Users and software alike use the subject line to file replies into neat “threads”.
Unfortunately, knowing the subject line and which person replied to whom at what point in time can tell you a lot even if you can’t read the message contents.
So now you’re forced to choose between perfect operational security discipline 100% of the time and using software in a totally normal way.
Nation-state spy agencies use metadata to decide who to kill.
If you care about privacy, you should never send this kind of extremely sensitive metadata in the clear.
Even if you take nation states off the table, private intelligence companies like Palantir and their international competitors are almost certainly up to no good.
DKIM (RFC 4871), published in 2007, is an Internet Standard with near-universal adoption among email providers.
Without getting too technical, DKIM publishes a digital signature of every message sent from an email server. This signature was intended as an anti-spam measure, since the original email protocols were extremely permissive about senders.
In practice, this means that every email you send (even if it’s encrypted) has an additional layer of non-repudiation baked into it.
This means that, for example, every email you’ve ever sent through Gmail can be cryptographically proven to have been sent through Gmail’s servers. Even worse, this proof can be verified without Google’s involvement.
Non-repudiation is not a desirable property for private communications, as Ryan Castellucci explains in their blog post, DKIM: Show Your Privates.
At this point you might be wondering (especially if you work in tech), “Why hasn’t anyone tried to fix this?”
The main blockers for any proposal to fix email (updated RFCs, better use of encryption) have nothing to do with technology and everything to do with politics.
Repeat after me: all technical problems of sufficient scope or impact are actually political problems first.
Eleanor Saitta
Despite being an open protocol, email is (in practice) an oligopoly.
You cannot code your way out of social or political problems. Not directly, anyway.
At the very first year of the Crypto & Privacy Village at DEFCON (the year following the Snowden leaks), Adam Caudill proposed SMIMP as a way to make email secure and leak less metadata.
Neither SMIMP nor any other proposal to make emails private and secure have gained traction with the oligopoly that controls email, nor the governments that regulate them.
I need to emphasize, this isn’t due to a lack of awareness or effort. The big players have no incentive to change.
Setting aside that the “anti-regulation” party controls the United States right now, governments love to surveil their citizens..
Don’t believe me? Look no further than the EU’s recent Chat Control debacle for evidence of this. Just because a government launders their large-scale surveillance laws through the language of “keeping children safe” or “stopping terrorism” doesn’t mean that wasn’t their actual goal all along. The purpose of a system is what it does.
When you ask most people about privacy laws, they’ll blurt out something akin to “I have nothing to hide” and stop thinking about it entirely. You can draw a neat line between citizen apathy towards online privacy and the inertia on fixing email security by the big tech players.
Until the political climate changes, don’t count on email ever being fixed.
Please resist the temptation to think if you use a VPN service or a service like ProtonMail (which uses PGP) that you can magically be more secure than everyone else. It doesn’t work like that.
Here are some questions to ask yourself:
If you stare at any of these vendors for long enough, you’ll find that they provide at best a homeopathic level of privacy against any sophisticated adversaries.
Just don’t bother with email encryption. It’s a doomed effort.
I know that sounds rude or dismissive, but the situation is completely terrible and there’s no real political will to fix it. And you need political will to fix it.
Header art by CMYKat.