Everything You Need to Know About Email Encryption in 2026
好的,我现在要帮用户总结这篇文章的内容,控制在100字以内。首先,我需要通读整篇文章,抓住主要观点。 文章主要讨论了电子邮件的安全性问题。作者指出,电子邮件就像明信片一样缺乏保密性,加密邮件的努力因为技术、政治和社会因素而失败。特别是提到PGP和S/MIME的漏洞,以及DKIM签名导致的非否认问题。 接下来,文章分析了加密邮件在实际使用中的常见失败模式,比如用户不小心发送未加密的回复。此外,电子邮件的元数据(如收件人、主题、时间戳)也会暴露大量信息。 作者还提到,尽管有技术上的解决方案被提出,但由于大公司的利益和政府监管的阻碍,这些方案难以实施。最后,作者建议不要使用加密邮件,因为它无法真正保护隐私。 现在我需要将这些要点浓缩到100字以内。确保涵盖电子邮件缺乏保密性、技术漏洞、元数据泄露、政治因素阻碍改进以及加密邮件的局限性。 可能的结构是:首先说明电子邮件的安全问题,然后提到技术上的失败和元数据泄露,接着指出政治因素是主要原因,并最后建议放弃加密邮件。 现在试着组织语言: “文章指出电子邮件缺乏保密性,类似明信片。尽管存在PGP等加密方法,但因技术漏洞、用户失误及元数据泄露等问题难以实现有效保护。此外,政治和社会因素阻碍了改进努力。” 检查字数:大约70字左右。还可以添加更多内容吗?比如提到DKIM签名或非否认问题? 修改后: “文章指出电子邮件类似明信片,缺乏保密性。PGP等加密方法因技术漏洞、用户失误及元数据泄露等问题难以有效保护隐私。此外,政治和社会因素阻碍了改进努力。” 这样大约75字左右。 </think> 文章指出电子邮件类似明信片,缺乏保密性。PGP等加密方法因技术漏洞、用户失误及元数据泄露等问题难以有效保护隐私。此外,政治和社会因素阻碍了改进努力。 2026-1-4 22:2:9 Author: soatok.blog(查看原文) 阅读量:13 收藏

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.

Why People Want to Encrypt Email

Email is not simple. Even before you get into protocol discussions, email is actually several things bundled into one software package:

  • The most basic mental model for email is an asynchronous “store-and-forward” message sent from you to other parties.
    • Not to mention the notion of Cc: and Bcc: fields.
  • Email addresses are an identity anchor for most of the Internet.
    • Forgot your password? Don’t worry, we’ll just… send you an email. Wow.
  • Mailing lists allow members of a group to send an email once and have everyone else receive an identical copy.

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:

  • SMTP, the protocol for sending email, rarely enforces TLS (if it’s even supported at all)
  • STARTLS, an opportunistic attempt to increase TLS usage for email protocols, is trivially stripped by active attackers
  • Emails are not end-to-end encrypted between inboxes

…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.

How Email Encryption Fails

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.

But you can forward/screenshot Signal…

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.

It Gets Worse, Of Course

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:

  • The To: and Cc: fields (and, practically, always the Bcc: field)
  • The subject line for the email
  • Timestamps
  • Attachment metadata (file names, types)
  • DKIM signatures (more on that in a minute)
  • IP addresses (this one is included for completeness, since people forget about it)

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.

But that’s just metadata!

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.

Enter, Non-Repudiation

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.

This is the worst of all possible worlds

  1. You have virtually no email privacy. They’re like postcards, not envelopes.
  2. Anyone that sees your email can effectively prove you sent it (modulo your account or provider getting hacked).
  3. Even if you try to staple encryption onto your message contents, enough metadata gets leaked to still harm you.

At this point you might be wondering (especially if you work in tech), “Why hasn’t anyone tried to fix this?”

Email Cannot Be Salvaged

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.

Protocol Upgrades Have Been Proposed Before

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.

Privacy Tech Companies Are Not Silver Bullets

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:

  1. How are secret keys managed?
  2. How are public keys managed? (Trust on first use, web of trust, etc.?)
  3. Where does the encryption take place, and where does that code come from?
  4. What doesn’t get encrypted? (Subject lines, etc.)
  5. How does this work for people not using the same service? Does everything silently downgrade to plaintext?

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.

TL;DR

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.


文章来源: https://soatok.blog/2026/01/04/everything-you-need-to-know-about-email-encryption-in-2026/
如有侵权请联系:admin#unsafe.sh