systemslibrarian/crypto-lab-pq-tls-handshake

# crypto-lab-pq-tls-handshake 浏览器端基于 X25519MLKEM768 混合后量子密钥交换（draft-ietf-tls-ecdhe-mlkem-04，2026 年 2 月，命名组代码点 0x11EC）的 TLS 1.3 握手模拟。 ## 它是什么 该项目完全在浏览器中（无需后端服务器）演示 TLS 1.3 握手双方，使用混合密钥交换 `X25519MLKEM768`： - 客户端密钥共享构造： - `X25519_pub (32)` + `ML-KEM-768_pub (1184)` = `1216` 字节 - 服务器密钥共享构造： - `X25519_pub (32)` + `ML-KEM-768_ciphertext (1088)` = `1120` 字节 - 混合共享密钥： - `X25519_shared (32)` + `ML-KEM_shared (32)` = `64` 字节 混合共享密钥通过 `HKDF-Extract` 与 `HKDF-Expand-Label` 输入标准 TLS 1.3 密钥调度（RFC 8446 第 7.1 节），与 TLS 对 `(EC)DHE` 的预期完全一致。 应用包含与纯 X25519 TLS 的并排对比，以可视化大小增加与延迟影响。 ## 何时使用 当您希望了解以下情况时，请使用此演示： - 理解现代浏览器和 CDN 在当前真实 HTTPS 连接上协商的内容 - 教授 TLS 1.3 部署的混合 PQ 迁移策略 - 检查字节级握手帧格式与线上的 `0x11EC` 组 - 研究为何 TLS 1.3 密钥调度逻辑无需协议变更即可支持混合共享密钥 - 在单一交互工具中比较经典与混合握手的大小与延迟行为 本工具不用于生产 TLS：这是一个教育模拟，并非 hardened TLS 栈。生产环境请使用成熟的库与运行时。 ## 在线演示 https://systemslibrarian.github.io/crypto-lab-pq-tls-handshake/ ## 可能的问题 - **ClientHello 分片**：1216 字节的密钥共享载荷可能将握手消息推至 MTU 边界附近，触发对分片敏感的中间设备。 - **实现侧信道**：JavaScript/TypeScript 中的教学代码不是恒定时间的，不适合保护长期密钥。 - **降级与互操作陷阱**：组支持不匹配、扩展处理或中间设备篡改可能强制非混合路径。 - **未来密码分析意外**：混合方案在至少一个原语幸存时提供保护，但假设仍需持续审查与修补。 - **慢链路延迟放大**：更大的 Hello 消息在受限或高丢包网络上可能更明显地增加握手延迟。 ## 实际使用 `X25519MLKEM768`（`0x11EC`）在 `draft-ietf-tls-ecdhe-mlkem-04` 中定义，并取代早期部署标识符如 `X25519Kyber768Draft00`（`0x6399`，已弃用）。 截至 2025 年 9 月中旬，Cloudflare 报告约 43% 的人工 HTTPS 连接使用混合后量子密钥交换。Chrome 在 M124 中默认启用混合，Firefox、Edge、Brave 与 Opera 亦提供支持。 这使得混合 PQ TLS 成为活跃互联网中使用最广泛的 post-quantum 密码机制之一。 ## 本地开发 ``` npm install npm run dev ``` ## 验证 ``` npm run verify:phase1 npm run verify:phase2 npm run verify:phase3 npm run verify:phase7 npm run build ```

标签：0x11EC 组, HKDF, HTTPS, key share 构造, MTU 边界, PQ 迁移, Side-by-side 比较, SSL/TLS 握手, TLS 1.3, X25519MLKEM768, X25519 仅加密, 代码片段, 共享秘密, 前端密码学, 字节级帧, 实时演示, 密钥调度, 延迟影响, 开源实验, 握手大小, 数据可视化, 暗色界面, 浏览器模拟, 混合后量子密码, 演示工具, 自动化攻击, 草案 draft-ietf-tls-ecdhe-mlkem-04