外观
VMax MVP 密码协议候选设计
1. 状态
- 状态：候选设计，待总控决策，未冻结协议版本或密码套件。
- 适用范围：MVP 的同实例、单设备、一对一文本消息。
- 禁止结论：本文不表示候选组合已实现、已互操作、已审计或可用于生产。
2. 需求来源分类
v1.1 MUST
- 不从零发明密码原语或协议；使用公开规范、经过审查的实现和固定测试向量。
- 未知协议版本默认拒绝；能力升级建立新会话，不在会话中静默换套件。
- 所有签名/认证相关对象采用确定性编码并提供跨语言测试向量。
- 解析具有长度、版本和未知字段策略；消息重放、乱序和密钥变化必须测试。
- 生产发布前必须完成独立密码学审计，并关闭或书面接受严重/高风险问题。
说明书建议方案
- 身份认证：Ed25519 + ML-DSA-65 混合签名。
- 异步会话：PQXDH 风格，X25519 + ML-KEM-768 或 X-Wing。
- 持续会话：Double Ratchet + Sparse PQ Ratchet/Triple Ratchet。
- 消息 AEAD：ChaCha20-Poly1305 或 AES-256-GCM。
- KDF：HKDF-SHA-256 或 HKDF-SHA-512。
这些是组合建议，不是规范中单一、完整且已审计的“VMax Protocol v1”。组合边界、平台 API 和实现许可证均未决。
当前已验证事实
- 仓库尚无可验证的协议实现或测试向量。
- 2026-09-23 只读核对的 GitHub License API 将
signalapp/libsignal标识为AGPL-3.0、cryspen/libcrux标识为Apache-2.0、openmls/openmls标识为MIT。这不替代逐文件、依赖传递和发布方式的法律审查。 - Protocol Buffers 官方说明其序列化不是通用 canonical serialization；不能只打开 deterministic 选项就把输出当作长期签名字节。
3. 协议候选
候选 A 直接集成 libsignal
边界：复用上游支持的握手和 ratchet 实现，不对内部格式做未授权改造。
优势：接近公开 Signal 规范及其实际实现；避免自行重写大量 ratchet 状态机。
风险：
- 代码许可当前标识为 AGPL-3.0；分发 iOS App、服务边界、修改和链接方式必须由法务确认。
- 上游公开 API、Apple 平台适配、构建链和版本升级需要实证。
- “使用 libsignal”本身不证明 VMax 的身份、存储、通知、备份和错误处理安全。
验证：许可证书面意见；最小 iOS 构建/尺寸/性能 spike；上游向量；跨版本迁移；FFI 内存与错误审计。
候选 B 依据公开规范组装经审查原语
边界：使用平台或审查过的 X25519、ML-KEM、签名、HKDF 和 AEAD，实现明确版本的握手与 ratchet 状态机。
优势：可控制 API、编码、许可和 iOS 集成；可选择 Apache-2.0 等宽松许可的原语实现候选。
风险：协议组合、状态机、侧信道、错误恢复和互操作责任全部落到 VMax；“原语经过审查”不等于“组合协议经过审查”。后量子建议尤其不能作为安全证明。
验证：逐条规范追踪矩阵、差分测试、独立实现互操作、固定/负向向量、模糊测试、第三方密码审计。
候选 C 先发布经典协议 后续迁移 PQ
优势：实现复杂度和平台依赖较低，可先验证消息状态与运维闭环。
风险：不能满足把持续后量子保护作为首版承诺的产品口径；已收集密文无法事后获得“现在收集、未来解密”防护。升级设计若不预留会话重建和版本拒绝，容易产生降级。
验证：产品范围批准、对外文案检查、版本迁移演练、降级攻击测试。
4. 待总控决策 01 协议实现路线
| 选项 | 安全成熟度 | 许可/发布风险 | 工程风险 | 推荐用途 |
|---|---|---|---|---|
| A libsignal | 相对更接近成熟实现，但 VMax 集成仍需审计 | AGPL-3.0 影响待法务确认 | iOS/FFI/升级未知 | 优先做限时可行性与许可 spike |
| B 公开规范 + 审查原语 | 组合未审计 | 可选择宽松许可，但需逐依赖核对 | 最高 | 仅在 A 不可接受且有审计预算时继续 |
| C 经典先行 | 可采用成熟经典方案 | 取决于实现 | 中 | 仅在产品明确撤销首版 PQ 承诺时可选 |
推荐：先并行完成 A 的许可书面意见和 iOS spike；同时为 B 做最小互操作原型，不实现生产代码。没有证据前不冻结 A 或 B，不以 C 静默降级。
5. 套件与版本框架
套件标识必须代表完整且不可拆分的参数集合，至少绑定：
- 协议主/次版本；
- 身份签名算法和组合规则；
- 初始握手算法、transcript 规则和密钥确认；
- ratchet 变体、KDF、AEAD；
- 规范化编码版本；
- 限制参数，如最大跳跃、最大消息和预密钥类型。
禁止用自由字符串拼接算法并由接收端“选择能解的部分”。未知版本或不完整套件必须失败关闭。升级需要新握手/新会话，并把旧/新套件协商结果纳入认证 transcript。
6. 必须绑定的上下文
以下字段必须进入签名 transcript、KDF context 或 AEAD AAD；具体归属由最终规范冻结：
- 实例稳定标识和实例长期公钥指纹；
- 发送/接收身份与设备标识；
- 协议版本、套件、编码版本；
- 预密钥标识及一次性消费语义；
- 会话标识、消息标识、消息序号/ratchet 公钥；
- 内容类型、填充类别和与安全有关的到期语义。
服务端接收时间、展示时间和可修改路由字段不得成为端到端安全的唯一依据。
7. 联系人身份验证语义
协议认证证明“某消息由持有相应设备/会话密钥的一方产生”，不自动证明服务器最初提供的公钥属于用户想联系的人。MVP 使用分层验证状态：
| 等级 | 含义 | 建立方式 | 密钥变化后的状态 |
|---|---|---|---|
| L0 未验证 | 只有地址/搜索结果，尚未接受身份密钥 | 输入地址或收到请求 | 保持 L0；不得显示安全勾 |
| L1 已固定 | 首次接受并固定身份公钥，仍可能受首次 MITM | TOFU/接受联系人请求 | 立即降级并阻断警告 |
| L2 二维码已验证 | 用户面对面/可信带外比较完整安全码 | 扫码或逐段比较 | 立即失效；重新验证前不能恢复 |
| L3 透明日志验证 | P1 候选，不在 MVP | 独立透明日志机制 | 由未来规范定义 |
身份/预密钥包必须把实例身份、用户随机 ID、身份公钥、设备公钥和预密钥授权关系纳入签名。二维码/安全码至少绑定实例完整指纹、双方身份公钥指纹和格式版本；不能只比较短地址或实例短码。
验证状态属于本地安全数据：服务端不能提升等级，备份/恢复后要保留来源和时间，身份密钥变化事件不能被普通“接受新密钥”提示静默覆盖。
8. 状态机要求
- 预密钥包必须由身份授权的密钥签名，并绑定实例和设备。
- 一次性预密钥在服务端原子领取；客户端仍必须抵抗服务端重复发放和握手重放。
- 解密必须先在隔离的候选状态上验证；AEAD 成功且消息通过重放检查后再提交 ratchet 状态。
- 跳跃消息密钥缓存必须有数量、年龄和总字节上限；超限拒绝不得破坏可用旧状态。
- 消息去重不能只依赖服务端 ACK；客户端按会话和消息标识持久化重放状态。
- 身份密钥变化必须中断已验证状态，不允许通过新握手静默恢复 L2。
- 任何解析、签名、KEM、KDF 或 AEAD 错误均返回稳定错误类别，不回显秘密或做细粒度远程 oracle。
9. 后量子组合仍需回答的问题
- 混合密钥如何组合：串接后 HKDF、嵌套 KDF，还是遵循所选公开规范的精确定义？
- KEM 密文、签名和 transcript 的编码、域分离标签及失败行为是什么？
- “两个签名均通过”是否为最终规则；传统或 PQ 分支不可用时是否一律拒绝？
- 持续 PQ 注入的触发参数、并发冲突、丢包恢复和状态存储如何定义？
- iOS 平台 API 是否覆盖所需算法、系统版本和 Secure Enclave 边界？这由 ADR-002 和 iOS 任务验证。
- 未来算法撤销如何在不降级、不中断联系人验证语义的情况下迁移？
在这些问题通过规范、向量和审计前，不得将 VMAX_X25519_MLKEM768_... 当作可发布套件。
10. 测试与发布门槛
- 每个规范对象都有黄金向量与负向向量：位翻转、截断、重复字段、非最短编码、未知版本、错误套件、错误实例。
- 至少两个独立语言/实现对同一向量得出相同 transcript、派生密钥和密文。
- 覆盖乱序、重复、重放、巨大 ratchet gap、预密钥并发、崩溃前后状态提交。
- 模糊测试解析器和状态机；固定资源上限并监控 CPU/内存。
- 审计范围包含协议组合、原语调用、随机数、密钥生命周期、FFI、持久化、侧信道和错误处理。
- 未完成许可证审查、向量冻结和独立审计，不得进入生产发布。
11. 工程路线边界
- Swift/SwiftUI 客户端承载端到端协议；Go 服务只处理认证、公开预密钥、密文投递和 ACK，不实现消息解密。
- PostgreSQL 是密文队列和安全状态的持久权威；Redis/队列只能加速短期协调，丢失后必须能从 PostgreSQL 恢复，且不能重复消费一次性预密钥。
- S3 兼容对象存储属于附件 P1；图片、视频和附件不进入文本 MVP，也不能借本协议初稿暗中启用。
- Docker 镜像不包含实例私钥、测试密钥或调试后门；具体部署和 secret 管理由服务端/运维任务设计。
12. 参考资料
- Signal PQXDH specification: https://signal.org/docs/specifications/pqxdh/
- Signal Double Ratchet specification: https://signal.org/docs/specifications/doubleratchet/
- libsignal repository and license metadata: https://github.com/signalapp/libsignal
- NIST FIPS 203 ML-KEM: https://csrc.nist.gov/pubs/fips/203/final
- NIST FIPS 204 ML-DSA: https://csrc.nist.gov/pubs/fips/204/final
- Protocol Buffers non-canonical warning: https://protobuf.dev/programming-guides/serialization-not-canonical/