Twitter/X加密消息协议的进一步分析

Matthew Garrett最近发布了一篇关于Twitter（现称X）新端到端加密消息协议XChat的文章。从密码学角度来看，XChat表现不佳。以下是关键问题总结：

主要安全问题

缺乏前向保密性 与Signal协议使用双棘轮持续更新用户密钥不同，XChat仅使用接收方的长期公钥加密每条消息。实际加密机制基于libsodium加密方案。

用户私钥存储在X服务器 XChat将用户私钥存储在自己的服务器上。用户需通过PIN等密码登录X的密钥存储系统获取私钥，这与Meta为Facebook Messenger和Instagram加密采取的方法类似，但那些服务使用了硬件安全模块（HSM）。

基于Juicebox的密钥存储 XChat使用名为Juicebox的协议实现密钥存储系统。Juicebox将密钥材料"分片"存储在三台服务器上，理论上单台服务器的丢失或泄露不会造成损害。

Juicebox系统深入分析

密钥存储困境 端到端加密应用面临用户密钥存储难题。用户常丢失设备或拥有多个设备，导致密钥管理困难。Web浏览器等无状态客户端更增加了复杂性。

密码强化方案 Juicebox是基于软件的分布式密钥强化服务，可在多台服务器上实现。用户将账户注册到系统后，Juicebox服务器将其PIN/密码转换为强加密密钥。系统能承受N-T台服务器的丢失，并在攻击者攻破A<T台服务器时保持安全。

核心加密原语：阈值OPRF Juicebox核心密码学原语是阈值不经意伪随机函数（t-OPRF）。OPRF是两方密码协议，帮助客户端和服务器联合计算PRF输出：

• 服务器拥有密码密钥K
• 客户端拥有字符串P（如密码）
• 协议运行成功后，客户端获得O = PRF(K,P)，服务器无任何输出

攻击向量分析

• 攻击者可尝试少量密码猜测，等待真实用户登录重置尝试计数器
• 如果服务器间不协调，攻击者可对不同服务器子集尝试密码猜测
• 恶意服务器操作者可能直接攻击协议

XChat部署现状

根据与Juicebox协议设计者Nora Trapp的交流，XChat的Juicebox部署存在严重问题：

• 所有领域（realm）似乎都由Twitter/X自己在软件中运行
• 即使某些领域运行juicebox-hsm-realm代码，时序分析表明它们可能使用不安全的"软件HSM"
• 没有发布任何设置仪式，无法验证是否真正使用HSM

结论

除非X证明他们正在使用HSM（并已销毁所有编程卡），否则应假设其Juicebox实例基于X控制下的软件领域，容易受到暴力密码猜测攻击。在当前状态下，XChat无法提供真正的端到端加密安全保障。

本文详细分析了XChat加密协议的技术实现和安全隐患，为密码学爱好者和安全研究人员提供了深入的技术见解。