Voron 加密/协议库 — 评审请求

这是一个小型 E2EE 即时通讯项目的加密与消息协议核心，被单独提取出来供外部评审。它不是完整产品——Android 客户端和部署配置被有意排除在外；这只是需要接受审查的部分。

这里包含什么

• common/ — 库本身：
  • e2ee/ — X3DH-lite（异步密钥协商）+ 其上的 Double Ratchet，基于 Curve25519/ChaCha20-Poly1305/Ed25519/HKDF 构建（JDK 提供的原语，该层没有任何手写实现）。
  • crypto/ — 对这些 JDK 原语的薄封装。
  • group/ — 通过 sender-keys 方案实现群组消息（早期 WhatsApp/Signal 群组使用的 MLS 前身方法），外加客户端签名的哈希链事件日志用于成员/角色记录，因为中继对群组完全没有概念。
  • onion/ — 可选的分层加密传输（固定跳数、大小分桶填充），防止中继将连接的 IP 与其身份密钥直接关联。
  • client/、transport/、backup/ — 线路协议、Noise_IK 传输握手和加密备份格式。
• server/ — 参考中继实现：存储转发路由、预密钥目录、离线邮箱、洋葱跳角色。刻意保持最小信任：中继永远看不到明文，消息投递完成后不会保留更久，并且（按设计）对群组成员身份完全没有感知。
• client/ — 一个普通的 JVM 控制台测试工具（不是真正的应用），用于在集成测试中驱动 common/server 相互配合，外加几个独立的漏洞利用 PoC（见下文）。
• security-audit/ — 先前内部评审轮次的报告、发现的问题以及已修复的问题。在报告问题之前请先阅读这些内容——很可能已经在这里面了。REPORT.md 是主要文档；ADVERSARIAL_REVIEW_PAVEL.md 是后来范围更窄的评审；fuzz/ 和 client/.../exploit/ 包含可运行的 PoC，而不仅仅是描述。

威胁模型，简版

• 中继不是受信任方。它路由密文和目录数据（已发布的预密钥），并且被假定为主动恶意，而不仅仅是好奇——security-audit/ 中几个已修复的 bug 恰恰就是“恶意中继能做什么”这类问题。
• 1:1 会话旨在实现前向保密（X3DH）和后妥协安全（其上的 DH 棘轮）。群组会话使用 sender-keys：成员变更会为整个群组重新生成密钥，但单个被攻陷的发送方密钥会暴露该纪元（epoch）的消息——群组层没有逐消息棘轮（不是完整的 MLS/TreeKEM，这是有意的范围裁剪，记录在 group/GroupCryptoSession.kt 中）。
• 洋葱路由对只看到一个跳的中继隐藏 IP↔身份关联，并将帧填充到固定大小分桶，使跨跳的被动大小相关性无法轻易对电路去匿名化。它不能对同时观察两端的攻击者隐藏时间相关性——那需要掩护流量/混合，而这尚未实现。这一点在 security-audit/REPORT.md 和 ADVERSARIAL_REVIEW_PAVEL.md 中已被明确说明，并非隐瞒。

我们特别希望被审查的内容

• X3DH-lite ↔ Double Ratchet 集成（common/src/main/kotlin/messenger/common/e2ee/）——这是这里唯一真正定制的加密构造，其下的一切都是现成组件。它已在内部接受过多次评审（见 security-audit/），但从未有本项目之外的任何人审查过。
• 群组控制日志的授权模型（common/src/main/kotlin/messenger/common/group/GroupControlLog.kt）——一个完全没有任何服务器强制执行的客户端签名哈希链。
• 洋葱路由层中任何未被上述已记录的时间相关性警示所涵盖的内容。

运行方式

./gradlew test

标准的 Gradle/Kotlin 项目，需要 JDK 17+。单元级测试套件不需要网络访问或运行中的服务。security-audit/README.md 包含实时中继模糊测试和洋葱相关性 PoC 的说明，这些需要本地进程在运行（切勿将其中的任何内容指向生产主机）。

这不是什么

本代码尚未经过独立的密码学审计。security-audit/ 中的所有内容都是内部工程评审——认真细致，但属于自我评审，没有形式化证明支撑，也没有专业/机构层面的业绩记录。请将其视为评审的起点，而非认证。