TL;DR（省流总结）
端到端加密群聊（Group E2EE）的难度远不止「把单聊加密套到群里」这么简单。每新增一个群成员，密钥分发复杂度呈 O(n²) 指数增长。Signal 用「发送者密钥」（Sender Keys）绕过了早期方案的天花板，而 IETF 推行的 MLS 标准（Messaging Layer Security，RFC 9420）则用异步树结构在数千人大群中跑通了亚秒级加密。但两个方案都有坑：前者丢消息风险高，后者实现成本大得离谱。
引言：为什么没人告诉你群聊加密有多难？
2023年底，我们团队被一个客户的问题搞到头皮发麻：他们要在企业内部部署一个3000人的加密通知群，要求消息必须端到端加密——不是「传到服务器再加密下发」那种假E2EE，而是密钥只存终端、服务器永远碰不到明文的那种。
当时我第一反应：”这不就是Signal群的超大号版本吗？”结果调研了两周，挖出来的坑深到能把我自己埋了。
先做个铺垫。如果你还不清楚单聊的端到端加密聊天（End-to-End Encrypted Chat, E2EE Chat）是怎么工作的，建议先看那篇基础科普。本文假定你已经理解了单聊的 DH 密钥交换和双棘轮（Double Ratchet）机制。
问题一：密钥分发的「平方爆炸」
一对一聊天里，你和 Bob 只需要一把共享密钥。但当你把 Alice、Bob、Charlie、Diana 四个人拉进一个群，如果沿用一对一逻辑——每个人都要和群内其他成员各建一个独立的加密通道——那就是 4 × 3 / 2 = 6 对密钥。
500人的群呢？500 × 499 / 2 = 124,750 对密钥。
每对密钥要经历 X3DH 握手、生成初始棘轮状态、预密钥上传……这些操作不是免费的，每一条都需要时间和电量。当年 WhatsApp 的早期实现就走的就是这条路，结果是：进入一个大群的初始化延迟达到了20秒以上，而且每有一个人退出/加入，全群需要重新协商——再来一次。
这在2018年之前是行业公认的无解问题。直到 Signal 祭出了「发送者密钥」（Sender Keys），才把一个 O(n²) 的问题降到了 O(n)。
Signal 的 Sender Keys：聪明但不是万能
Sender Keys 的核心思想是反直觉的：既然每对都建通道太贵，那就别建了。
具体做法：每个群成员生成一把自己的「发送者密钥」（一个对称的 AES-256-CBC 密钥），用自己与群内每个成员之间的双棘轮通道分别传输这把密钥。之后这个人发的所有群消息，只用自己的 Sender Key 加密一次，然后把同一份密文广播给所有人。
这会带来两个后果：
- 发给 N 人的群消息，从「加密 N 次」变成「加密 1 次 + N 次分发密钥（仅初始一次）」——消息发送速度翻了 N 倍
- 但每换一个人加入或退出，Sender Key 必须替换，全群需要重新分发——这就是「重钥延迟」
关于双棘轮在单聊中的完整工作机制，我们之前的 Signal协议与双棘轮加密详解有逐层拆解，这里不再展开。
Sender Keys 在中小型群聊（30人以内）的表现接近完美。但我们那个3000人大群的需求一出来，问题就暴露了：每有人离职/入职触发一次全群重钥，延迟从毫秒级飙升到十几秒。这不是 Signal 代码写得烂，而是Sender Keys 的架构从根上就不是为超大群设计的。
MLS：树结构杀出来的第三条路
2023年7月，IETF 正式发布了 MLS（Messaging Layer Security）RFC 9420。这个长达132页的标准，我在第一次读的时候差点扔键盘——但搞懂之后，不得不服这群密码学家把二叉树玩到了极致。
MLS 的核心数据结构叫「异步棘轮树」（Asynchronous Ratchet Tree, ART）。简单说：
- 每个群成员是树的叶子节点
- 每个内部节点包含一个公钥
- 树的根节点公钥就是整个群的共享秘密
- 当有人加入或离开时，只需要更新从该叶子到根的路径上的节点密钥——而不是全群
这意味着什么？在 Sender Keys 里，Alice 退出 → 全群500人都要重新协商。在 MLS 里，Alice 退出 → 只更新树中与她相关的 log(N) 个节点——500人群约9个节点，5000人群约13个节点。
从 O(n) 降到了 O(log n)。
但 MLS 的代价也摆在明面上：实现复杂度是 Sender Keys 的5倍以上。我在主流的 E2EE 通讯工具中实测对比过五款安卓端到端加密通讯App，截至2026年5月，没有一款完全实现了 MLS。大多数还在用 Sender Keys，或者自己魔改的混合方案。
| 对比维度 | Pairwise（一对一对） | Sender Keys（Signal方案） | MLS（RFC 9420） |
|---|---|---|---|
| 成员变更代价 | O(n²) 全量重建 | O(n) 全量重分发 | O(log n) 路径更新 |
| 100人大群延迟 | 30-60秒 | 2-5秒 | <1秒 |
| 实现复杂度 | 低 | 中 | 极高（需维护树状态） |
| 前向安全性 | ✅ 双棘轮保障 | ⚠️ 发送者密钥泄露影响段内消息 | ✅ 树层级更新保障 |
| 后向安全性 | ✅ 重钥即恢复 | ⚠️ 依赖重分发时机 | ✅ 路径更新即恢复 |
实战：企业大群加密部署到底踩了多少坑
回到那个3000人大群的项目。我们在真实部署中踩过的坑，大家当反面教材看：
坑1：密钥分发窗口期的丢消息
Sender Keys 的重分发不是瞬时完成的——3000人的群，分发一圈要跑4-8秒。在这几秒窗口期内，如果有人发消息，部分成员收不到（因为还在用旧密钥解密新消息→解密失败→客户端静默丢弃）。我们上线第一周收到了27条”漏消息”的反馈。
解决方案：引入「密钥过渡窗口」——新旧 Sender Key 并列留存5秒，用密钥 ID 标注每条消息用的是哪个版本。但这意味着每条消息的头部多了 4 个字节，3000人 × 每天200条消息的群，一年多吃掉将近900MB的额外流量。
坑2：离线成员的密钥黑洞
有人三天没上线，回来时 Sender Key 已经更新了三轮。客户端的处理逻辑是：先拉取新密钥→解密积压消息→但积压消息用的是旧密钥加密的→解密失败→用户看到一堆”消息无法解密”。
这件事的根因是 Sender Keys 的「对称性」：加解密的密钥必须完全一致，没有不对称恢复机制。MLS 在这方面做了改进——用树结构中存储的父节点公钥可以推导子节点密钥，但实现起来需要对 libmls 做深度定制。
坑3：管理的噩梦——密钥审计
这一点在企业场景特别要命。如果用端到端加密替代企业微信，合规团队一定会问：管理员能不能审计群消息？答案是——Sender Keys 和 MLS 都做不到。这就是加密与合规的天然矛盾，我们会在下一篇专门聊法律层面的文章里深入讨论。
群聊加密 SOP 检查清单
如果你正在选择或自研一个支持 E2EE 群聊的方案，对着这张清单走一遍能帮你少踩一半的坑：
设计阶段
- ☐ 明确最大群规模是多少（30人以下用 Sender Keys 够用；50人以上必须考虑 MLS 或混合方案）
- ☐ 确定「前向安全性（Forward Secrecy）」和「后向安全性（Post-Compromise Security）」的最低要求
- ☐ 评估是否需要支持「消息引用/回复」的加密一致性（引用原文需要能解密才能显示预览）
实现阶段
- ☐ 密钥分发必须有「重叠窗口」机制，避免成员变动期的丢消息
- ☐ 离线成员的密钥要保存历史版本，至少保留最近3个 Sender Key 周期
- ☐ 每个密钥操作记录元数据日志（不记录明文），方便事后排查”为什么这条消息解密失败”
测试阶段
- ☐ 模拟大群频繁加人/踢人的压力测试（每分钟2次成员变动 × 持续1小时）
- ☐ 模拟50%成员离线48小时后再上线的消息恢复测试
- ☐ 跨平台一致性验证：iOS加密→Android解密→Windows解密，三条链路全部走通
FAQ
Q: 我的App群聊最多50人，需要切换到MLS吗？
A: 不需要。50人的群在 Sender Keys 下表现完全够用，延迟在1秒以内。MLS 的实现和维护成本远高于它带来的性能提升。建议等到群规模超过100人、且出现可感知的延迟问题时再评估迁移。
Q: Sender Keys 和 MLS 用户端感受有区别吗？
A: 在50人以下的群里几乎没有区别。区别体现在：大群频繁变动成员时是否卡顿、离线回来消息是否大面积解密失败、以及——管理员审计能力 MLS 稍微好一点点（因为树结构可以支持部分审计路径，但这需要额外开发）。
Q: 自研一个群聊加密方案要多久？
A: 基于开源库（如 signal-protocol 或 openmls），20人以内的小群做 POC 大概2周。但要生产可用（含密钥管理后台、异常恢复、跨平台联调），3人团队至少4个月。如果从零手写——建议直接放弃。
Q: 端到端加密群聊和频道广播有什么区别？
A: 本质区别是：群聊要求「双向安全」——发消息的人加密，收消息的人解密，密钥双方协商。频道广播（如Telegram Channel）通常是「单向加密」——发布者加密后上传，服务器解密后广播（或直接不加密）。后者不是真正的 E2EE。
参考来源
- IETF RFC 9420 – The Messaging Layer Security (MLS) Protocol，2023年7月发布，定义了端到端加密群组通讯的标准协议。
- Signal Blog – Technology Preview: Signal Private Group System，详细阐述了 Sender Keys 的设计原理和取舍。
- IACR ePrint – TreeKEM: A Tree-Based Group Key Agreement Protocol，MLS 的学术前身论文，解释了异步棘轮树的数学基础。
