更安全的加密群聊 - Trail of Bits技术博客
MLS实现助力协议规范完善
我们开发的Rust实现项目molasses主要通过单元测试和互操作性测试发现了MLS草案6规范中的关键错误。例如规范存在导致无法添加群组成员的设计缺陷，这类问题必须通过自动化测试才能发现。通过持续的问题发现/修复循环，我们有效推动了协议规范的迭代优化。
加密群聊构建原理
MLS协议设计核心在于解决效率问题。与常见聊天应用不同，MLS是底层协议而非完整应用，不处理群组权限等高层逻辑，仅关注消息传输和成员移除机制。
典型案例场景
Wilna团队需要策划惊喜活动，但通信平台管理员Vince能监控所有服务器消息。传统中心化群聊方案存在隐私泄露风险，需要满足：
- 成员可广播/读取消息
- 中转服务器无法解密内容
- 区分应用消息（文本内容）和辅助消息（密钥管理）
方案1：点对点通道
每个成员间建立独立加密通道（N人群体需N(N-1)/2个通道）。发送消息需单独加密多次：
- 优点：实现简单
- 缺点：消息复杂度O(N)，万人群组单条消息需9999次加密
方案2：发送者密钥
每个成员维护自己的发送密钥，通过点对点通道分发：
- 初始设置需O(N²)辅助消息
- 消息发送仅需1次加密
- 致命缺陷：成员变动时需全量重新分发密钥
方案3：树状结构（TreeKEM）
MLS采用二叉ratchet树结构：
- 叶节点对应成员
- 中间节点含DH密钥对
- 密钥派生遵循树状属性：节点私钥仅其后代成员知晓
成员移除流程示例：
- 空白化被移除节点及其祖先
- 更新节点生成新密钥链
- 通过树状路径定向分发新私钥（仅加密给需要知晓的子树）
- 典型情况下辅助消息复杂度降至O(logN)
极端案例分析显示，当树结构严重不平衡时仍可能退化为O(N)复杂度，这是当前协议待解决的核心问题。
现状与展望
- 非平衡树处理效率
- 密钥派生方案调整（草案7已重构密钥表）
- 形式化验证需求
现有其他实现包括：
- mlspp（参考实现）
- MLS*（F*形式化验证）
- melissa（Wire的Rust实现）
选择Rust实现molasses的优势：
- 内存安全保证
- 清晰的API设计
- 43%的代码注释率
- 零成本抽象带来的高性能
我们持续通过实现实践推动协议规范完善，已发现包括树节点修剪逻辑、WelcomeInfo密钥包含等关键规范问题。欢迎通过IETF MLS工作组参与协议讨论。