外观
ADR-001 协议实现与许可
- 状态：提议，待总控决策
- 日期：2026-09-23
- 决策范围：MVP 同实例、单设备、一对一文本消息的端到端协议实现路线与第三方许可
- 关联：ADR-002、ADR-004、ADR-010，
docs/security/密码协议.md
背景
v1.1 要求不自行发明未经审计的密码协议，推荐 PQXDH 风格握手、Double Ratchet/Sparse PQ Ratchet/Triple Ratchet 及经典+后量子组合，同时明确 libsignal 的许可必须评估。推荐组合并非单一、已审计的 VMax 实现。
当前仓库没有生产协议实现或互操作向量，无法验证 iOS 构建、FFI、性能、持久化、升级和密钥删除行为。
不可变约束
- 未知版本/套件失败关闭，不允许静默降级。
- 协议对象有规范化编码、固定向量和严格资源上限。
- 服务端不接触私钥或明文。
- 生产前独立密码学审计、许可证/SBOM 审查和降级攻击测试完成。
- 不对外宣称“与 Signal 同级”或把后量子候选写成已验证能力。
- Swift/SwiftUI 客户端负责 E2EE；Go/Docker 后端、PostgreSQL、Redis/队列和未来 S3 对象存储都不得解密内容。Redis 不得成为唯一消息存储；图片/视频/附件不进入文本 MVP。
已核对事实
- 2026-09-23 GitHub License API 将
signalapp/libsignal标识为AGPL-3.0。 - 同日 API 将
cryspen/libcrux标识为Apache-2.0；它是原语/验证实现候选，不是完整 VMax 一对一消息协议。 openmls/openmls标识为MIT；MLS 面向未来群聊评估，不属于 MVP 一对一替代方案。- 上述标识不构成法律意见；必须核对精确 commit、子目录、传递依赖、构建产物和分发方式。
选项
A 直接集成 libsignal
- 优点：最大程度复用成熟状态机和上游实现经验。
- 缺点：AGPL-3.0 对目标发布模式的义务待法务确认；iOS 构建、FFI、API 稳定性和 PQ 能力需 spike。
- 失败条件：无法获得书面许可结论；目标功能不在上游受支持 API；无法满足 App Store、构建或审计要求。
B 按公开规范组装经过审查的原语
- 优点：API、编码、许可和平台集成可控；可选择宽松许可原语。
- 缺点：协议组合、ratchet 状态、侧信道和错误恢复均由 VMax 承担；审计成本最高。
- 失败条件：无第二实现互操作、无完整负向向量、无法为组合取得独立审计。
C 经典协议先行 后续新增 PQ 套件
- 优点：工程和平台风险较低。
- 缺点：不能延续“首版具备持续后量子保护”的产品口径；升级和降级设计复杂。
- 前提：产品负责人明确批准范围/文案变化，并建立新会话迁移而非静默降级。
建议
暂不接受任一生产路线。先完成两个有时限的证据任务：
- A：以固定 libsignal commit 做 iOS 构建、最小握手/ratchet、尺寸、性能、线程和持久化 spike，并取得书面许可意见。
- B：用候选原语做不进入生产的互操作原型，产出规范追踪矩阵、向量目录和审计工作量估算。
证据齐备后由总控选择 A 或 B。若两者都不可接受，再由产品明确评估 C；不得由工程自行移除 PQ 或降低宣传边界。
取舍
- 推荐优先评估 A，是为了减少自行实现状态机的风险，不表示认可 AGPL-3.0 对当前发布模式兼容。
- 保留 B 可避免许可或平台不可行导致项目停滞，但必须预算更高的协议与实现审计。
- 许可决策与开源策略相互依赖；ADR-010 仍需冻结仓库许可证、分发物和贡献策略。
决策证据门槛
- 法务书面说明：链接、修改、分发、网络交互、源代码提供和 App Store 条款的义务。
- 精确依赖清单、许可证文本、NOTICE、SBOM 和供应链来源。
- iOS 真机构建与性能：启动、握手、每消息、存储、升级、后台和内存。
- 协议能力矩阵：身份绑定、异步握手、乱序、重放、前向保密、入侵后恢复、PQ 注入。
- 跨语言固定/负向向量与版本迁移/降级测试。
- 独立审计范围和报价覆盖组合协议、FFI、持久化、随机数、删除和侧信道。
待总控决策
- 选择 A、B 或经产品批准的 C。
- 若选 A，是否接受 AGPL-3.0 义务或另有经法务确认的授权路径；本 ADR 不假设商业许可存在。
- 若选 B，批准规范负责人、第二实现、审计预算和禁止生产上线的阶段门。
- 是否把 PQ 作为 MVP 发布硬能力；若是，冻结前不得做对外安全声明。