systemslibrarian/crypto-lab-key-mirror

# Key 镜像 **密钥透明性 · 仅追加认证映射 · IETF KEYTRANS** 一个可以对一个用户撒谎而对另一个用户说真话的密钥目录，以及使这种谎言可被检测到的仅追加 Merkle 结构加上 gossip 机制。 ## 它是什么 每个端到端加密系统都有一个分发公钥的服务器。加密（这里指：X25519 ECDH → HKDF-SHA-256 → AES-256-GCM）回答了“*还有其他人能读取这个吗？*”——它无法回答“*我加密给的是谁的密钥？*”如果服务器**进行欺诈（equivocate）**——向 Alice 展示 Bob 的替换密钥，而向 Carol 展示真实密钥——此时加密是完美的，但安全性为零。 本演示首先针对真实的密码学运行该攻击，然后逐层构建防御： - **RFC 6962 Merkle 树**（纯手工编写，可检查）：叶/节点哈希、审计路径、一致性证明，以及独立的 RFC 9162 验证器——锁定到规范的 Certificate Transparency 参考树向量。 - **ed25519 签名的树头和绑定**（@noble/curves）。 - **ECVRF-EDWARDS25519-SHA512-TAI**（RFC 9381，基于 @noble/curves 点运算纯手工编写）用于标签隐私——锁定到所有三个 Appendix B.3 向量。 - **X25519 + HKDF + AES-GCM** 密封盒（RFC 7748 KAT）作为攻击所依赖的 E2EE 层。 安全模型：**目录服务器就是攻击者**。客户端验证所有客户端可以单独验证的内容（签名、包含性、一致性）；对欺诈的检测还需要跨用户比较记录（gossip）和自我监控。透明性是**检测，而非预防**——演示在页面中说明了这一点，因为攻击者确实会读取在检测之前发送的消息。 **非生产级密码学——仅作为教学演示。** 密钥材料在每次加载页面时生成，且仅存在于内存中；不会有任何数据离开浏览器。 ## 展示内容 1. **谎言** —— 将目录切换为恶意模式，逐步查看 Alice 的查找过程，她的 AES-GCM 加密消息如何落入 Mallory 的密钥中，Bob 毫不怀疑地收到重新加密的转发，以及 Carol 获得了真相。密码学结果和安全判定分别呈现：每个标签都验证通过 *且* 判定结果为警报。 2. **分层防御** —— 在第 0-4 层运行相同的攻击：纯信任、签名响应、包含证明、一致性证明、gossip。第 0-3 层在谎言依然存在的情况下通过了所有真实检查；第 4 层为同一个 epoch 生成了两个具有不同根的有效签名树头——这就是欺诈的可转移证明。 3. **逐字节的一致性证明** —— 让真实的 RFC 9162 验证器逐步处理诚实的追加（证明验证通过）和分叉的历史记录（重建不匹配，逐字节显示）。 4. **标签隐私** —— 真实的 ECVRF 将用户名映射到树槽位：对持有证明的用户是可验证的，对观察者是不透明的；翻转证明的一位，验证器就会拒绝。 5. **监控** —— Bob 审计他自己发布的历史记录并找到了被植入的密钥，附带有包含证明：攻击者不得不留下收据。 ## 何时使用 - 教授为什么 E2EE 通讯软件（WhatsApp 密钥透明性、iMessage 联系人密钥验证、Signal 计划中的 KT）需要透明层。 - 解释*身份验证*（第 1 层）、*成员资格*（第 2 层）、*仅追加历史记录*（第 3 层）和*全局一致性*（第 4 层）之间的区别——以及为什么单独每一层都不够。 - 展示 CONIKS/Parakeet/KEYTRANS 血缘系统实际能检测到什么，以及不能检测到什么。 - **不要**将其用作密钥透明性实现、KEYTRANS 线格式参考，或作为任何特定部署系统安全的证据。这里的 Merkle 日志是一个扁平的绑定日志，而不是 KEYTRANS 的 VRF 寻址前缀树。 ## 在线演示 —— 切换恶意开关，运行拦截，攀登防御阶梯，逐步查看失败的分叉证明，推导并篡改 VRF 标签，以及审计 Bob 的历史记录。 ## 可能出现的问题 - **根据设计，位于 gossip 层之下的欺诈是无法检测到的** —— 这是本实验室的论点，通过通过的证明来展示，而不是断言。 - **Gossip 只能检测被比较的视图之间的谎言**：如果 Alice 从不与任何人比较树头，她的分叉将一直存在。保证来源于覆盖范围，而非精巧设计。 - **检测是追溯性的。** 在检测之前发送到被替换密钥的消息将被永久破解。 - **监控需要参与**：只有在 Bob（或他的设备，或委托的监控器）实际进行审计时，才能发现以 Bob 的名义植入的密钥。 - **首次使用信任（TOFU）依然存在**：客户端首次接受的树头锚定了之后的一切。 ## 实际应用 - **WhatsApp** 提供了基于其可审计密钥目录（Parakeet 血缘）构建的密钥透明性。 - **Apple iMessage** 联系人密钥验证让设备自动交叉检查密钥目录。 - **IETF KEYTRANS WG** 正在将本演示教授其信任机制的认证映射结构标准化。 - **Certificate Transparency** (RFC 6962/9162) 是指向 X.509 证书的相同机制 —— CT 记录域名的证书，KT 记录用户身份的公钥。 ## 如何在本地运行 ``` npm install npm run dev # local dev server npm test # 50 unit tests incl. spec KATs npm run build # typecheck + production build npm run test:a11y # axe WCAG 2.1 A/AA gate, both themes (needs: npx playwright install chromium) ``` ## 相关演示 - [vrf-gate](https://systemslibrarian.github.io/crypto-lab-vrf-gate/) — 本实验室链接的完整 ECVRF 构造，用于深入了解 - [merkle-proofs](https://systemslibrarian.github.io/crypto-lab-merkle-proofs/) / [merkle-vault](https://systemslibrarian.github.io/crypto-lab-merkle-vault/) / [pki-chain](https://systemslibrarian.github.io/crypto-lab-pki-chain/) — Merkle 树和 Certificate Transparency - [x3dh-wire](https://systemslibrarian.github.io/crypto-lab-x3dh-wire/) / [ratchet-wire](https://systemslibrarian.github.io/crypto-lab-ratchet-wire/) / [mls-group](https://systemslibrarian.github.io/crypto-lab-mls-group/) — 其密钥目录由 KT 审计的消息传递协议 ## 构建与验证 - **50 个 Vitest 测试，全部通过**，包括： - RFC 6962 Merkle KATs — CT 参考树：空树哈希、所有 8 个增量根、5 个审计路径向量、4 个一致性证明向量（`src/merkle/kat.test.ts`）； - RFC 9381 Appendix B.3 ECVRF KATs — 完整的示例 16–18（pi、beta、H 和 try-and-increment 计数器），证明和验证（`src/vrf/ecvrf.test.ts`）； - RFC 7748 §6.1 X25519 KAT 和 FIPS 180-4 SHA-256 KATs； - 每个验证器的失败即关闭（fail-closed）拒绝测试，证明在第 0–3 层通过而视图分叉的攻击测试，gossip 检测和监控发现； - UI 步进器的追踪验证器锁定到真实验证器（`src/merkle/trace.test.ts`）。 - **无障碍访问检查**：`@axe-core/playwright` 在**两种**主题下扫描生产构建，并将每个展示内容驱动至其最丰富的（警报）状态；要求零 WCAG 2.1 A/AA 违规，并在部署前于 CI 中强制执行。 ## 性能 所有证明都基于玩具大小的日志（≤ 33 个叶子）；每次交互都在几毫秒内完成。ECVRF 证明只需几次曲线乘法（约 1 毫秒）；这里没有任何对性能敏感的内容。 *[Crypto Lab](https://crypto-lab.systemslibrarian.dev/) 套件中 170 多个浏览器演示之一。* *“所以，你们或吃或喝，或做任何事情，都要为神的荣耀而行。” —— 哥林多前书 10:31*

标签：Merkle树, Web前端, 密码学, 密钥透明度, 手动系统调用, 教育演示, 特征检测, 端到端加密, 自动化攻击