ActivityPub实现E2EE前的长尾工作

# ActivityPub 拥有端到端加密之前还有多少工作要做 —— Dhole Moments 来源：https://soatok.blog/2026/07/15/the-long-tail-of-work-left-until-activitypub-has-e2ee/ 抛开我为联邦宇宙提出的密钥透明性方案（https://publickey.directory/）不谈（我当然写过很多博客了），W3C 一直在推进 ActivityPub 的端到端加密（E2EE）工作（https://github.com/swicg/activitypub-e2ee）。 这两个项目基本是独立开发的，但将它们连接起来应该很简单（https://github.com/swicg/activitypub-e2ee/issues/35#issuecomment-3738855995）。 在我准备收尾、宣布我这边的工作“功能完整”，并考虑为规范和参考实现打上主要版本 1.0.0 标签时，我觉得有必要梳理一下需要完成的工作，以便最终落地——部分原因是，这正是**大多数技术人员可以开始做出有意义贡献的地方，而无需具备安全或密码学专业知识**。 与我大多数博客文章（有些博主称之为“常青内容”）不同，我完全预期这篇文章会随着工作的完成而逐渐过时。 为了条理清晰，我将从期望的最终状态倒推，深入剖析每项工作所需的先决条件，然后给出一个路线图——如果你读完了前面的内容，这个路线图应该不会让你感到意外。 ## 倒推工作 这是一项复杂的工程，所以我认为最好先从将期望的最终状态提炼成三个明确的目标开始。 **基本目标**：联邦宇宙用户应能互相发送端到端加密消息，并可包含附件。这必须高效支持群组消息，而不仅仅是 1:1 消息。目前正在通过 Emissary 和 Bonfire（https://socialwebfoundation.org/2025/12/19/implementing-encrypted-messaging-over-activitypub/）实现，底层协议是 Messaging Layer Security (MLS, RFC 9420)（https://www.rfc-editor.org/rfc/rfc9420.html）。 **安全目标**：用户应能确信端到端加密已正确执行，并且使用的是正确的封装密钥。 为此，每个封装密钥（在 MLS 中称为 KeyPackages（https://www.rfc-editor.org/rfc/rfc9420.html#name-key-packages））*必须*由用户（使用非对称数字签名算法）在客户端签名。 **真实性目标**：签名密钥必须可验证地由用户控制，且任何人都能验证这一属性。此验证不能依赖中央权威。 真实性目标正是密钥透明性发挥作用的地方。通过提供一个仅追加的密码学透明性日志，记录哪个 Actor（按 ActivityPub 术语）控制哪些签名密钥，可以构建一个去中心化的信任根。这就是过去几年**我的关注点**（https://soatok.blog/category/technology/open-source/fediverse-e2ee-project/）。 这些目标相互依存： - 如果不满足基本目标，所有这些工作对最终用户来说都没有实际回报。 - 如果不满足安全目标，端到端加密就必须附带一个巨大的、谁都不想要的星号。 - 如果不满足真实性目标，想要支持 E2EE 的联邦宇宙客户端将退回到安全号码或密钥指纹技术——这些技术连我尊重的专业密码学家自己都懒得用，因此对大多数人来说也不是现实的期望。 我们首先尽可能分开讨论这三个工作流。 #### 为什么做点什么而不是什么都不做？ > **注**：这是博客文章最初发布后添加的，因为它是重要的背景信息。 现状如下： - 今天的私信不使用端到端加密 - 无论司法管辖区如何（https://soatok.blog/2025/07/09/jurisdiction-is-nearly-irrelevant-to-the-security-of-encrypted-messaging-apps/），以明文形式存储敏感信息和附件对联邦宇宙实例运营者来说在法律上都很危险（https://www.eff.org/deeplinks/2023/07/fbi-seizure-mastodon-server-wakeup-call-fediverse-users-and-hosts-protect-their） - 欧盟将 ChatControl 1.0 编入法律也值得注意 这可能让一些人感到惊讶，但发送裸照或视频是很多成年人想做的正常事情（希望是在征得收件人同意的情况下）。 但如果你拥有大量的此类内容，这些实例就会成为色情勒索或报仇色情攻击的肥羊。如果你的某个实例管理员变坏或一开始就是个坏人，这也是一个风险。 端到端加密通过*不将任何明文存储在联邦宇宙实例服务器上*来缓解大部分风险。 关于威胁建模的更多信息，请参见我之前的博客文章（https://soatok.blog/2026/06/30/soatoks-informal-guide-to-threat-models/）。 ### ActivityPub 的 E2EE 基本目标（如我上面所定义）正由 SWICG 的 ActivityPub E2EE 项目团队（https://github.com/swicg/activitypub-e2ee）（W3C 的一部分）推进。他们的大部分工作可以通过阅读草案规范（https://swicg.github.io/activitypub-e2ee/mls）和 GitHub 上的问题跟踪器（https://github.com/swicg/activitypub-e2ee/issues）来了解。 为了实现这一目标，他们显然需要与最终用户联邦宇宙客户端相关的各种编程语言的 MLS 实现。 例如，ts-mls（https://github.com/LukaJCB/ts-mls）是一个支持后量子密码学的 TypeScript MLS 实现，OpenMLS（https://openmls.tech/）是一个 Rust 实现，ts-mls 正在与之进行互操作性测试。 目前有一个后量子 MLS 的互联网草案（https://www.ietf.org/archive/id/draft-ietf-mls-pq-ciphersuites-05.html）正在 IETF MLS 邮件列表中讨论（https://mailarchive.ietf.org/arch/browse/mls/）。最新草案包括我为一种密码套件注册的条目（https://mailarchive.ietf.org/arch/msg/mls/goy5Lzp4Sqht5fUSQTXJuzpR9hU/）（并推荐给了 ActivityPub E2EE 项目（https://github.com/swicg/activitypub-e2ee/issues/59））。 正如我在之前博客文章中提到的（https://soatok.blog/2026/06/30/soatoks-informal-guide-to-threat-models/#distributed-e2ee），一致的消息排序是使 MLS 分布式化（https://datatracker.ietf.org/doc/draft-xue-mls-decentralized/）需要解决的关键难题。前面提到的 RFC 草案讨论了一些在大规模下解决此问题的方法。 ### 满足安全目标 采用 E2EE 的联邦宇宙客户端需要能够验证 KeyPackages。 这是整个过程中最简单的部分： - 客户端软件必须管理数字签名算法的密钥材料（例如 Ed25519、ML-DSA）。 - 生成 KeyPackages 的客户端软件必须包含有效的数字签名，使用上述密钥和正确的算法。 每个密钥都对应一个公钥。为了满足安全目标，需要一种机制来确保拥有其他每个用户的*正确*公钥。请参见：真实性目标。 这个工作流中要做的事情很少，因为它主要需要将另外两个工作流以不易受算法混淆或密钥替换攻击的方式粘合起来。 ### 联邦宇宙规模的真实性 有几种关于如何在联邦系统中验证用户身份公钥的思想流派。在开始动手之前，了解各种可能的解决方案非常重要。 以下是在联邦宇宙规模上解决真实性问题的几种可能方法中的三种： 1. **证书颁发机构**。这就是我们今天用于 TLS 证书的模式。这是一种已知的模式，但同时也是中心化的，容易受到政府和企业腐败的影响。 2. **密钥指纹**。在 activitypub-e2ee#43（https://github.com/swicg/activitypub-e2ee/issues/43）中讨论过，其想法是创建用户公钥的确定性指纹，以便用户当面或通过某些现有的受信任渠道进行验证。 3. **密钥透明性**。我写了 activitypub-e2ee#35（https://github.com/swicg/activitypub-e2ee/issues/35）来提议将此作为解决方案。 我通常认为证书颁发机构不适合社交网络。我这里没有具体的技术论点，只是觉得对于联邦宇宙来说有点太“证件检查”了，我们都可以少一些那种氛围。 关于剩下的两种，密钥指纹技术将所有责任都推到最终用户身上，要求他们不被欺骗（https://decentsecurity.com/#/how-you-get-infected/），而密钥透明性更像是一种群体免疫导向的解决方案，可以在后台运行，提高基线而不触及天花板。 两者并非互斥。客户端应用可以实现一种类似交通灯协议的方案。大致如下： - 🟢**绿色**：以下两个条件都为真。 - 用户已验证密钥指纹/安全号码，当面扫描了二维码，或以其他方式手动执行了某个验证步骤 - 公钥可以独立于密钥透明性日志进行验证。它未被撤销。 - 🟡**黄色**：满足了一种机制（密钥透明性、手动公钥验证），而另一种缺失。 - 避免手动操作的用户会习惯看到很多黄色。 - 🔴**红色**：警告最终用户（但要小心）。 - 如果两种机制都无法满足（一个陌生人发送了私信，但没有将其公钥发布到透明性日志中），应告知用户。 - 如果用户的公钥因帐户被盗（https://github.com/fedi-e2ee/public-key-directory-specification/blob/main/Specification.md#revokekeythirdparty）或恢复操作（https://github.com/fedi-e2ee/public-key-directory-specification/blob/main/Specification.md#burndown）而被撤销，或者发生密码学错误，那么用户对通信的任何信任都无法通过密码学延伸，这一点应向用户清楚解释。 这不是协调两种机制的唯一方法，也可能有更好的方法值得考虑。我当然不是用户体验专家，开发者在发布任何东西之前应该咨询专业人士。 此外，关于这些机制局限性的透明性（哈哈）至关重要。 - 密钥透明性涉及公钥的持有证明（并自动处理轮换）。 - 手动验证是针对特定公钥的本地信任断言（如果身份密钥轮换，新密钥必须手动重新验证）。 - 两种机制都不证明加密是安全的；这由不同的层处理。 - 两种机制或 E2EE 都不证明终端设备是安全的。你的对话可能是私密的，但这并不能阻止其他人成为恶棍。 “信任”一词常常被含糊地滥用，意指以下一种或全部：“密码学身份验证”、“真实性”、“机密性”和“社会信任”。我们必须（开发者和用户）发展出一个共享的词汇来讨论这些话题，以尽量减少混淆。 我有自己的看法，但我没有答案。这需要一场对话。 话虽如此，我从 2024 年开始一直在研究一个基于密钥透明性的解决方案，用于实现真实性目标，所以这是我最新掌握的知识。 #### 为什么不直接把公钥塞进个人资料然后就完事呢？ > **注**：这是在博客文章最初发布后添加的，因为它回答了一个我以为很明显的问题。 正如我之前对这篇博客文章的补充（https://soatok.blog/2026/07/15/the-long-tail-of-work-left-until-activitypub-has-e2ee/#why-not-nothing）中提到的，这类解决方案的威胁模型的一部分是恶意的服务器管理员。 如果你只是把公钥塞进个人资料元数据中，什么能阻止你的实例运营者用另一个公钥替换它？其他人又如何检测到？ 密钥透明性方面的工作只控制了一个**仅用于数字签名的长期密钥对**的公钥部分。 这些不是封装密钥（又称非对称或“公钥加密”密钥）。封装密钥属于 MLS 的 KeyPackages，计划中不将其记录在密钥透明性系统中。然而，KeyPackages 将由公钥存储在透明性系统中的密钥对进行*签名*。 > 如果这对你来说听起来很奇怪，你应该知道 TLS 1.3 也是这样工作的（https://tls13.xargs.org/）！对临时封装密钥进行签名是保留前向安全性的同时，将整个机制绑定到某个身份密钥上的方法。在 TLS 的情况下，它是证书。在我们的情况下，它是透明性日志。有空可以查查“认证密钥交换”。这个博客上最早的文章之一（https://soatok.blog/2020/04/21/authenticated-key-exchanges/）就涉及了它们，但那是 6 年前的事了。 ## 尚待跨越的桥梁 好了，如果你读到了这里，你应该已经了解了*目标是什么*以及这些目标为什么重要。 说实话，我们可以追求无数其他可能的目标，但我相信这种框架能帮助我们尽快为联邦宇宙带来最佳结果。 > "* (甩了甩我蓬松的大$$$$尾巴)" —— 标题图片中同款艺术下方的 Deltarune / Undertale 文字框风格文本。 > 艺术作者：mebbie（https://mebbie.carrd.co/）（是的，我也玩 Deltarune lol :D） 现在让我们谈谈需要做什么才能达到目标。 ### 通往基本目标之路 为了拥有 ActivityPub 的端到端加密，我们需要客户端支持 MLS。 这需要拥有现有联邦宇宙客户端软件相关编程语言的、实现 MLS 的开源库。每个这样的开源库都需要至少支持一个共同的密码套件。 > 我向 SCIWG 推荐了两个后量子密码套件（https://github.com/swicg/activitypub-e2ee/issues/59），最新的 mls-pq-ciphersuites 草案（https://datatracker.ietf.org/doc/draft-ietf-mls-pq-ciphersuites/05/）包含了这两个。 在任何棘手的讨论开始之前，交付这项工作的基本条件是： 1. 更多语言中的更多 MLS 实现 2. 对支持哪些密码套件达成粗略共识（按 IETF 的含义） 3. 对这些实现进行更多的安全保障 但在跨越那座桥梁之前，有几个技术决策需要解决。 1. 元数据和一致的提交排序（https://socialhub.activitypub.rocks/t/activitypub-mls-message-ordering-metadata-and-bears-oh-my/8820） 2. 密钥承诺 / 消息标记 / 滥用举报（https://github.com/swicg/activitypub-e2ee/issues/87） 3. 如何处理大附件（https://mailarchive.ietf.org/arch/msg/mls/YtB1LoFA-5ohseJbFDMMrVWZ8NM/） 4. 消息备份 / 多设备 / 虚拟客户端 - MLS 工作组正在讨论的“虚拟客户端”RFC 草案（https://datatracker.ietf.org/doc/draft-ietf-mls-virtual-clients/）可能足以解决这个问题。 - 本质上，MLS 叶子节点可以秘密地成为其自己的秘密子树。你可以用这个来支持多设备，每个设备作为较大子树中的一个参与者。 - 这个子树工作也可能有助于对实际的联邦宇宙实例隐藏一些明文元数据，但这还不明确。 5. 双人配置档案 - 参见：two-