群组加密消息到底是如何运作的

Source: Dev.to

背景

在加密对话中加入第三个人看似应该很简单，但实际上并非如此。使一对一消息安全的密码学属性——前向保密、妥协后安全性、可否认性——随着群组规模的扩大，变得显著更难以保持。

当 Signal 引入群聊时，他们遇到了在一对一消息中不存在的问题：如何在保持强安全保证的前提下，高效地为多个收件人加密单条消息？最直接的答案——为每个收件人单独加密消息——虽然可行，但扩展性很差。

成对加密（Signal v1）

最简单的群聊实现是 成对加密：发送者为每个群成员建立一个独立的安全通道，并单独向每个人发送消息。由于每个通道都使用 Signal 协议（双棘轮），在每条消息时都会轮换密钥，这提供了完整的前向保密。

• 优点: 安全性高；每个成对通道的安全性等同于一对一会话。
• 缺点: 线性扩展——消息开销随群组规模线性增长。对于 100 人的群组，发送一条消息需要 100 次单独加密、100 次网络传输以及 100 次棘轮推进。

发送者密钥（Signal 当前）

Signal 当前的群组实现使用 Sender Keys 来解决扩展性问题。

1. 每个群组成员生成一个 Sender Key——一种链密钥，用于为该成员的出站消息派生一系列加密密钥。
2. Sender Key 会单独分发给每个群组成员（一次性成本）。
3. 之后，发送者使用其链中的当前密钥对每条消息进行一次加密。

这将后续消息的开销从 O(N) 降低到 O(1)。

• 权衡： Sender Keys 在哈希链上向前推进，能够对被动观察者提供前向保密性，但缺乏完整 Double Ratchet 的入侵后恢复能力。如果某成员的当前状态被泄露，攻击者可以在链重置之前解密后续消息。
• 结果： 前向保密性仍然得以保留，但事后妥协安全性较弱。

Membership Changes

在安全的群组消息中，最难的问题不是加密消息——而是安全地管理成员变更。

• 新成员的前向保密性： 新成员不得解密他们加入之前发送的消息。
• 移除后保密性： 被移除的成员不得解密以后发送的消息。要实现这一点，需要在移除后旋转群组密钥，对于 1,000 人的群组来说，这意味着在成对或 Sender‑Key 方案下进行 999 次单独的密钥分发。

Messaging Layer Security (MLS, RFC 9420)

Messaging Layer Security (MLS) 是从第一原理设计的，旨在大规模解决群组消息安全问题。

• MLS 用一棵 二叉树（即 “ratchet tree”）取代了成员变更时的 O(N) 密钥分发，树的叶子由群组成员占据，内部节点保存中间密钥。
• 当成员更新其密钥材料（一次 commit）时，只需更新从其叶子到根节点路径上的节点。在拥有 N 个成员的平衡树中，这只需要 O(log N) 次操作，而不是 O(N)——例如 1,000 名成员只需大约 10 次操作，而不是 999 次。

Epochs

MLS 引入了 epoch（时代）的概念——即群组状态的一个版本。每当群组成员发生变化或密钥材料被更新时，群组就会进入一个新 epoch。消息在发送时使用当时有效的 epoch 密钥进行加密。这提供了：

• 前向保密的明确边界。
• 通过切换到新 epoch 来从设备泄露中恢复。
• 群组状态变更的密码学审计轨迹。

Concurrency

在分布式系统中，两个成员可能会同时尝试推进 epoch——即 “并发 commit”。MLS 定义了解决机制，这增加了 Sender‑Key 方法所避免的复杂性。

Adoption (as of 2026)

• WhatsApp announced MLS adoption.
• Apple Messages began using MLS for group chats.
• Matrix has an MLS implementation in development.
• Haven uses MLS for encrypted group chat, specifically for the O(log N) membership‑change overhead and strong post‑compromise security guarantees.
• Signal continues using Sender Keys for large groups—both positions are defensible depending on group‑size distributions and adversary models.

比较表

安全群组消息应用的关键问题

1. 移除成员后，是否能阻止他们读取未来的消息？
2. 新加入的成员能否读取他们加入前的历史消息？
3. 群组协议是否有文档说明并经过独立审计？
4. 如果某个成员的设备被攻破，会发生什么情况？

在 1:1 场景下，前向保密性已被充分理解；在群组场景中，它需要明确的设计选择，而这些选择在不同实现之间差异显著。

Originally published at havenmessenger.com.