电子邮件加密

# 电子邮件加密 来源：https://computer.rip/2026-07-19-email-encryption.html 电子邮件作为计算机联网中最普遍且最持久的技术之一，诞生于 20 世纪 60 年代，由数十人在大约十几个地方各自发明。很难梳理出这项技术清晰的历史脉络，因为它实在太显而易见了——几乎从多个人能同时使用一台计算机开始，就出现了某种形式的邮件工具。这些工具的范围很广，从大型机中心式系统（同一台计算机的所有用户可互相发送消息），到 PC 中心式系统（工作站挂载网络共享来存储和检索消息）。大概从 20 世纪 60 年代到 90 年代，你能想到的任何消息传递方案，几乎都在某个地方使用过；而到了 90 年代，源自 ARPANET 的电子邮件实现家族才最终站稳脚跟。 这种形式的电子邮件有着更清晰的传承，其根源可追溯到雷·汤姆林森（Ray Tomlinson）。他提出了核心想法：地址既可以标识用户，也可以标识主机，并且必要时可以用某种开放协议将消息发送到另一台主机。随着时间的推移，经过多次修订，汤姆林森的设计演变成了 SMTP，并伴随 IMAP 等协议，构建了我们今天使用的电子邮件形式。这种形式的电子邮件在某些方面是去中心化的（任何用户都可以自由选择主机），在另一些方面又是中心化的（假设每台主机都持续在线，为其用户存储并转发消息）。汤姆林森的设计足够灵活，我们不必完全抛弃它，但现代互联网已经发生了太多变化，我们必须采取新的方法。 电子邮件有许多令人头疼的限制，这些都是其年代久远的产物。例如，电子邮件的处理不应假定为“8 位干净”——电子邮件协议最初是基于 7 位 ASCII 定义的，并且运行在许多将第八位用作校验和的机器上。这些机器容易改变每个字节的最后一位，或者以其他方式错误处理包含 8 位内容的电子邮件。当文本完全局限于那 7 位平面时，这不是问题，但 Unicode 的出现以及发送二进制文件的需求，使得 7 位电子邮件变得不可行。MIME 被开发出来作为一种变通方案，它是一种编码技术，通过将电子邮件的所有非 ASCII 内容编码为 ASCII 字符的形式，一次性解决了几个问题。 这相当不优雅。MIME 的 ASCII 编码，无论是 quoted-printable 风格还是 base64 风格，对人类阅读来说都很烦人，并且在消息大小方面效率低下。与所有类似 base64 的编码一样，它算是一种可疑的气味，表明我们正在掩盖过去的错误。电子邮件里充满了这样的东西。我们再考虑一个：安全性。 “互联网电子邮件”这个术语，我们可以用它来明确指代从 ARPANET 继承而来的 SMTP 类型电子邮件系统，其设计简单，源于网络计算机操作者都彼此认识的年代。虽然存在其他可能性，但大多数电子邮件都是直接发送到收件人的计算机上，而且在许多情况下，那个年代的主机级安全性也不太好。别人可能读取你的私人电子邮件——这一点是已知的，但你也做不了什么。互联网存在于一个信任的背景下。 今天我们不再给予同样的信任。电子邮件通常由双方各自的第三方邮件服务处理，这些服务不一定可信；而且要在两个第三方邮件服务之间传输，它必须经过一系列安全状况也堪忧的互联网链路。电子邮件成为大型计算机网络最早（可能也是第一个）令人信服的应用。它也可能成为该领域最早且持续存在的安全失败案例。该系统在设计时没有考虑消息的机密性或完整性，而且到今天，其中很大一部分仍然以这种方式运行。 尽管如此，改善电子邮件安全性的努力由来已久，我们或许应该从最伟大的一个开始讲起：它不仅是一个电子邮件协议，而是一整套承诺打造更好互联网的协议栈：OSI 协议簇。 ## X.400 现代互联网诞生于一个常被称为“协议战争”的时代。今天我们讲述互联网的故事时，往往将其简化为一条美好的线性叙事：ARPANET 被创建，大家都觉得这是个好主意，然后它就开始普及。这并非完全错误，但遗漏了许多其他参与者。电信行业以其对分组交换模式的反对而闻名，这种模式源自计算机行业而非通信行业，并且明显带有计算机行业的特征。在 20 世纪 70 年代和 80 年代，电信行业定义了自己的一套网络协议和基本的计算机网络方法，这后来被称为 OSI 协议簇。 今天，OSI 协议的相关性仅限于现代网络教材令人沮丧的坚持，即试图用“OSI 模型”来解释互联网，这是一个现在更多是推测性而非实际的层次模型，描述了一个与互联网不兼容的不同系统。学术界之所以对这种用失败的互联网的设计文档来解释另一个成功但根本不同的互联网架构有这种奇怪的执念……嗯，这本身就是协议战争的余波。历史可能由胜利者书写，但失败者仍然可以左右理论。 尽管我一直在努力劝阻人们使用 OSI 模型来学习，但我们确实可以从 OSI 协议中学到东西。TCP/IP 协议栈之所以能胜过 OSI 协议栈，原因有很多，其中之一是 OSI 的“委员会设计”方法导致了一组经过深思熟虑但相当复杂的协议。这与互联网协议形成了巨大反差，后者的设计哲学更接近“当下够用就行”。 这种哲学上的差异在应用层协议上尤为明显。按常规定义，“互联网协议簇”根本不包含应用层协议，这本身就是一个说明问题的事实。而 OSI 协议簇则包含。互联网电子邮件最初是作为 FTP 的一种特殊用例开始的，后来转为基于 Telnet 的一组松散命令，这些命令最终被正式化（或僵化，取决于你问谁）为 SMTP。 到 1984 年 OSI 标准发布时，人们已经知道电子邮件是杀手级应用之一——SMTP 的第一个修订版于 1982 年发布，是对互联网上电子邮件流行程度的事后回应，而且，自 20 世纪 70 年代以来，电子邮件一直是大多数专有网络系统的关键特性。因此，OSI 有了一个解决方案：X.400。 X.400 是 OSI 协议簇中的“消息处理系统”部分，提供了可识别为电子邮件但更为通用的功能。X.400 在大多数方面都是失败的。它几乎在所有环境中都未能取代互联网电子邮件。尽管如此，X.400 绝对具有影响力。曾有一段时期（尽管很短暂），人们认为主要政府会在未来的采购中要求 X.400 兼容性。这与 POSIX 兼容性成为政府要求的那段时期类似，并且产生了类似的效果：许多供应商设计其产品以满足要求，政府后来失去了兴趣，于是这成了一种奇特的历史遗留。在电子邮件领域，微软 Exchange 是最明显的例证：Exchange 最初是一个 X.400 实现，主要是出于政府原因，并且至今仍提供许多 X.400 特性。 X.400 比互联网电子邮件复杂得多。例如，X.400 消息的编码是 ASN.1，这是一种二进制序列化格式，比 MIME 更高效、能力更强，但也复杂得多。X.400 在复杂性上层层叠加，这有助于理解为什么 X.400 最引人注目的特性之一——加密——没有走多远。 如果你要给某人发送一封电子邮件，并且不想让其他人读到，最明显的方法是端到端加密。出于许多实际原因，你会想使用非对称加密。你找到收件人的公钥，用该密钥加密消息，然后像往常一样通过线路发送。收件人再用他们的私钥解密。这足够简单，但这个过程每个部分都充满了复杂性。 为了强调这一点，让我们看看 X.400 本身——1988 年的“蓝皮书”版本，这似乎最适合电子邮件僵化的时期。 > 支持上述特性的非对称密钥管理方案的一些方面，由目录系统认证框架提供，该框架描述于建议书 X.509。目录存储 MHS 用户的已认证公钥副本，可用于提供认证，并便于密钥交换，以用于数据机密性和数据完整性机制。证书可使用建议书 X.519 中描述的目录访问协议从目录中读取。关于其他类型密钥管理方案（包括对称加密）以支持安全特性的建议，有待进一步研究。 端到端加密电子邮件需要两个基本部分： 首先，必须有一种技术格式，用于在消息传输系统中传递加密消息。X.400 通过使用 ASN.1 定义轻松解决了这个问题，这些定义允许加密消息体，从而将大部分工作变成了别人的问题。X.400 实际上在安全特性方面考虑得更多，比如交付的不可否认性，这需要消息传输方面更多的复杂性，但未能延续到现代。我们现在暂时忽略这些。 其次，必须有密钥基础设施。你需要某种方式来获取你想要发送消息的人的公钥，并确保它确实属于他们。这对于加密外发电子邮件和验证入站电子邮件都很重要，因为端到端加密通常与端到端认证一起部署，使用相同的加密基础设施。对于 X.400，整个问题被推迟到 X.500 协议簇。 什么是 X.500？它是我们的老朋友，目录访问协议。X.500 目录标准是 LDAP 与之比较而显得“轻量级”的基准，这里有一个平行的故事：LDAP 是胜过 X.500 巨人的草根互联网协议。 所以，X.400 电子邮件安全性的要点是：使用目录查找收件人的公钥，然后用该密钥加密 ASN.1 消息对象的主体。实际上，细节不同且更复杂，但这对整个 OSI 来说都是如此，这里简化的草图足以抓住要点。这很直接。 只有两个问题：ASN.1 作为消息格式并未成功，而全球目录的概念从未实现。 在 X.400 取得成功的程度上，其安全特性实际上是一个很大的动机。ISODE 联盟（曾创建了 OSI 应用协议簇大部分内容的类似参考实现）今天仍以 Isode Ltd 的名义存在，并且仍在销售消息处理系统。还有几个其他维护中的 X.400 衍生系统。最大的客户群体之一是军方：虽然在美国不太常见（请记住，互联网电子邮件最初是在美国军方支持下开发的），但许多欧洲国家采用了 X.400 作为其安全消息解决方案，并且在军事和情报组织中仍然广泛依赖它。X.400 的其他持久据点包括全球航空（ICAO 的消息系统基于 X.400）和电子数据交换（EDI），这是一种 ERP 之间金融和供应链消息传递的标准化系统。 这些正是 X.25 等协议异常长期存活的同一类应用（表明它们与长期运行的遗留系统高度亲和），也是参与者和消息传递由中央实体管理的环境，这绝非巧合。这意味着存在一个目录，从而大大简化了密钥分发问题。这也意味着使用的软件——无论是传输代理（例如服务器）还是客户端——都是标准化的，并且通常从专门设计以在 X.400 环境中良好运行的供应商处购买。 换句话说，这些环境与电子邮件的环境截然不同。在电子邮件中，人们在大量组织之间交换消息，许多用户只是使用“邮件提供商”，这些提供商并非传统意义上的组织。这意味着电子邮件系统中没有有意义的目录能力。电子邮件还伴随着极其多样化的客户端环境，这对设计中的“需要与复杂目录系统交互的复杂消息编码”部分造成了严重的惩罚。 既然 X.400 在电子邮件世界的大部分领域都被证明行不通，那对于我们其他人来说，加密该怎么办？嗯，这种情况变得复杂且令人难过。 ## MIME 首先，更详细地解释一下 MIME（多用途互联网邮件扩展）的参与会有所帮助。MIME 最初是作为互联网电子邮件 8 位问题的解决方案而出现的，是一种以一致、可靠的方式编码非 ASCII 文本和二进制文件的方法。在实现这一目标的过程中，它引入了“多部分”消息的概念，即主体包含多个不同对象，而不仅仅是一串文本。我们今天大量使用这个多部分特性，既用于明显的应用（如文件附件），也用于更微妙的用途（如提供纯文本变体的 HTML 电子邮件）。我认为将 MIME 总结为“电子邮件 2.0”并不完全错，因为虽然它的范围仅限于消息格式（不改变传输协议），但 MIME 为电子邮件增加了许多我们现在认为是消息系统基本要求的新功能。 MIME 的历史比你想象的要多得多曲折，这反映了对一个像互联网电子邮件这样分布广泛且异构的系统进行重大更改的困难。尽管如此，MIME 的作者似乎也有类似的观点，即 MIME 通过标准化消息体并为未来对该标准的扩展铺平道路，从而增加了新功能，是电子邮件的一次重大演进。RFC 1521（1993 年，第一个 MIME 标准）中的这段话很有启发性： > STD 11，RFC 822 定义了一种消息表示协议，它详细规定了消息头，但将消息内容（即消息体）留作纯 ASCII 文本。本文档重新定义了消息体的格式，以允许多部分文本和非文本消息体在无信息丢失的情况下进行表示和交换。这基于 RFC 934 和 STD 11、RFC 1049 中记录的早期工作，但对其进行了扩展和修订。由于 RFC 822 对消息体几乎未作规定，本文档在很大程度上与 RFC 822 是正交的（而非对其的修订）。 换句话说，现有的电子邮件标准解决了消息如何在主机之间传输的问题，但对于消息实际包含什么内容却几乎未作规定。MIME 通过为消息体创建一个适当的标准来解决这个问题，该标准在增加功能的同时，也要应对许多 MIME 之前的电子邮件实现所固有的不幸限制。围绕 MIME 这一通用主题的许多 RFC（以及其他关于电子邮件体形式的提案）