摘要

  • RFC 10024 为 TLS 1.3 规定了三个最终的后量子/传统混合密钥协商组，将 ECDHE 与 ML-KEM 的共享秘密按固定顺序拼接后送入现有密钥日程。
  • “至少一个组件仍安全”是组合构造在特定假设下的目标，不是部署证书。RFC 10024 明确警告：若两个算法使用同一个不安全的 RNG，一个组件泄露发生器状态，就会影响另一个组件。
  • 审计不能只看组名。它必须把 ServerHello、转录、熵源、CSPRNG、进程、密码库、硬件模块、终止点、FIPS 边界与证书签名分别记录。

快照恢复之后，两个组件一起变得可预测

先从一个没有发生过、却足以检查架构的场景开始。

某云边缘节点从虚拟机快照恢复。启动检查显示 CSPRNG 正常，TLS 策略也列出 X25519MLKEM768。客户端发出包含 ML-KEM 封装密钥和 X25519 临时公钥的 ClientHello；服务器选择组 4588，校验密钥格式，生成 ML-KEM 密文与 X25519 份额，双方完成 Finished。监控系统因此写下“混合握手成功”。

问题是，快照恢复让进程回到了旧的发生器状态，而系统没有在恢复点强制重新播种。ML-KEM 封装所需的随机量与 X25519 临时标量都从这个进程级发生器取得。两种算法基于不同的数学问题，却沿着同一条已失效的随机性供应链运行。

这个例子不指向任何厂商，也不声称共享一个正常 CSPRNG 会自动破坏安全。它只追问：当组织把“两个算法”当成“两道独立防线”时，是否检查过它们共同依赖什么。

RFC 10024于 2026 年 8 月作为 IETF Standards Track 文档发布。它把最终版 ML-KEM 与临时椭圆曲线 Diffie-Hellman 组合，建立三个明确的 TLS 1.3 NamedGroup。设计目标是：即使一个组件算法被攻破，只要另一个组件仍安全，派生出的会话秘密仍应受到保护。

这个目标很强，但它保护的是组合中的密码学假设，不会自动审计执行环境。

三个编号不是三个抽象标签

RFC 9954给出了 TLS 1.3 混合密钥协商的框架。组合并不是让应用自己收集两个结果再拼装；每一种有序组合都被当作一个不透明 NamedGroup。组件的公钥或密文按固定顺序直接连接，组件共享秘密也按固定顺序连接，然后替代普通 (EC)DHE 秘密进入 TLS 1.3 的 HKDF 密钥日程。

因此，组名同时指定算法、参数、顺序与长度。

X25519MLKEM768 的 IANA 值是 4588。客户端份额先放 1,184 字节的 ML-KEM-768 封装密钥，再放 32 字节 X25519 份额，共 1,216 字节。服务器先放 1,088 字节 ML-KEM 密文，再放 32 字节 X25519 份额，共 1,120 字节。共享秘密也是 ML-KEM 的 32 字节在前、X25519 的 32 字节在后。这个顺序因为历史原因与 RFC 9954 的普通命名顺序相反。

SecP256r1MLKEM768 的值是 4587。客户端用 65 字节未压缩 P-256 点加 1,184 字节 ML-KEM 密钥；服务器用 65 字节点加 1,088 字节密文。64 字节组合秘密则是 ECDHE 在前、ML-KEM 在后。

SecP384r1MLKEM1024 的值是 4589。客户端和服务器份额各为 1,665 字节：97 字节 P-384 点与 1,568 字节 ML-KEM-1024 值。其秘密是 48 字节 ECDHE 坐标加 32 字节 ML-KEM 结果，共 80 字节。

固定长度让直接连接能够无歧义解析。也正因为如此，不能把任意两个密码学输出照此拼接，再借用 RFC 10024 的安全结论。

安全性依赖 TLS 转录，而不是“拼接”这个动作

当前 TLS 1.3 规范 RFC 9846把初始 ClientHello、可能出现的 HelloRetryRequest、第二个 ClientHello、ServerHello 与后续认证消息纳入转录哈希。服务器在 ServerHello 中选择的 key share 决定握手密钥；Finished 证明双方拥有由该转录与秘密派生的密钥。

RFC 10024 特别强调，其安全分析关键依赖 TLS 1.3 消息转录。相同的字节连接若被搬到另一个协议，并不会因为外形相似而继承证明。

这也是“运行证据”应保留的最小链条：客户端支持哪些组、实际发送哪些 key share、是否收到重试、服务器选中哪个组、组件检查是否成功、CertificateVerify 使用什么签名、Finished 是否完成。配置页写着“支持混合组”只能说明意图，不能替代一次具体连接的转录。

RFC 9794进一步清理了语言。PQ/T hybrid scheme 是至少含一个后量子组件与一个传统组件的多算法方案。“后量子”表达设计目标，不表示未来一定找不到经典或量子攻击。名字越准确，越应该限制结论，而不是扩大结论。

协议检查能拒绝坏值，却看不到随机源

RFC 10024 要求服务器对客户端的 ML-KEM 封装密钥执行 FIPS 203 的检查，失败时以 illegal_parameter 中止。客户端必须检查所选组的密文长度；长度不符同样中止。其他 ML-KEM 解封装失败产生 internal_error。ECDHE 组件也必须执行相应有效性检查，X25519 还必须拒绝全零共享秘密。

这些要求避免畸形输入悄悄进入密钥日程。它们没有越权声称：随机性来自独立健康的发生器；实现具有侧信道防护；另一个机房或 TLS 终止器运行同一策略；组件位于不同进程、不同库或不同硬件安全边界。

NIST FIPS 203标准化 ML-KEM，并列出 ML-KEM-512、768 与 1024 三个参数集。NIST 的表述是 ML-KEM 目前“被认为”能抵抗拥有量子计算机的攻击者。标准化给出共同算法，不替代实现正确性、持续密码分析和运行证据。

NIST SP 800-227提供 KEM 设计与安全使用建议，也讨论混合/组合构造。引用该文档可以说明设计依据，却不能证明某个二进制、HSM 或托管终止层执行了哪些建议。

RFC 已经把共同模式写进安全考虑

ML-KEM 封装会从随机比特发生器抽取随机量 m。客户端在解封装时能够恢复 m。RFC 10024 因此指出：如果 m 暴露了发生器其他输出的信息，客户端也会得到这些信息。

ECDHE 临时标量同样来自随机性，不过它不会被直接发送给对端。两种组件的输出形式不同，并不意味着它们的熵来源不同。

规范随后给出本文的核心边界：如果两个算法使用同一个不安全 RNG，一个算法泄露发生器状态，也会影响另一个算法的安全性。

“不安全”不能被删掉。一个经过正确设计、播种、重播种并隔离状态的共享 CSPRNG 不会仅因共享而失效。相反，把两台硬件随机数设备摆在机架里，也不能自动解决共同固件、共同熵源、共同升级通道或共同管理权限。

RFC 8937解释了初始熵为什么是共同根：如果多个 CSPRNG 实例都由弱或破损的熵源播种，它们可能一起失去不可预测性。该文档提出一种可选的随机性包装方式，把长期私钥操作产生的材料混入输出，以强化跨会话保障。是否部署这类机制必须由运行证据回答，不能从组 4588 推断。

随机源只是规范明说的例子。运维还要检查共同的密码库、内存空间、解析器、HSM 固件、构建签名、软件供应链、远程管理面与紧急回退开关。如果同一个远程代码执行漏洞能读出两个组件的状态，数学多样性仍在，运行故障域却只有一个。

FIPS 顺序决定谁承担认证要求

RFC 10024 还说明了组件顺序的合规后果。NIST 相关规则允许 HKDF 接受两个不同共享秘密，条件是第一个由 FIPS 批准的密钥建立方案生成。

在 SecP256r1MLKEM768 与 SecP384r1MLKEM1024 中，ECDHE 秘密位于前面。按 RFC 描述的使用方式，ECDHE 实现必须经过认证，而 ML-KEM 实现不因这一顺序条件被要求认证。在 X25519MLKEM768 中，ML-KEM 秘密位于前面，因此相应 ML-KEM 实现承担认证要求。

顺序不是安全排名。认证第一个组件也不等于认证第二个组件、组合代码、随机数发生器、策略或整个服务。审计记录应写出具体模块、版本、认证边界与它覆盖的组件，不能只写“FIPS-compatible”。

IANA 把词汇固定下来，没有批准部署

IANA TLS 参数注册表记录 4587、4588 与 4589。只有 X25519 组合的 Recommended 为 Y，两个 secp 组合是 N。注册表明确说明，N 不必表示有缺陷，也可能表示适用范围有限或面向特定场景。

试验期的 X25519Kyber768Draft00 与 SecP256r1Kyber768Draft00，值 25497 与 25498，已被 RFC 10024 标记为过时和不鼓励使用。监控若只显示“PQC”，就会把最终标准组和草案代码点混为一谈。

注册建立互操作名称，不证明某个客户端会提供它、服务器会选择它、所有边缘节点已经升级，或未来策略不会改变。IANA 也警告，密码算法会随时间削弱，不能盲目实现注册项。

2026 年 8 月 30 日查看 RFC 10024 勘误检索时没有显示记录。这只是带日期的注册表状态，不是对实现或未来解释的保证。

密钥协商完成，不等于认证完成

RFC 9954 明确把下一代认证排除在混合密钥协商范围之外。TLS 1.3 的 Certificate 与 CertificateVerify 是另一条认证链。一个连接可以正确选择 X25519MLKEM768，同时仍用传统签名验证服务器证书。

这并非标准遗漏。混合密钥协商首先处理“现在收集、未来解密”的机密性风险。已完成会话的认证不能在未来被回溯性改写；未来伪装与证书签名迁移是另一套时间表。

因此，组织至少要分开四个字段：本连接的密钥协商组、证书签名方案、TLS 实际终止点、应用最后授权的操作。把它们压缩成“后量子完成”，会让一个符号替代四个控制面。

Heng Lu 的运行代码优先要求把执行结果置于制度标签之前。配置与标准很重要，但真正的权威落在已选择的组、已验证的转录与已观察的服务行为。

最小初始规范、未来决策本地化与自愿采用解释了 RFC 的克制：共同层只需要定义可互操作的组合、编码与拒绝条件；组件选择、认证边界、共同模式风险和回退责任应留给承担后果的运营者。

现实层与符号权力提醒我们，“hybrid”是对一次复杂运行状态的表示，不是状态本身。技术控制与实际控制则追问：谁能够修改终止器、密码库、熵源、证书、遥测与回退按钮。只有回答这些问题，两个算法才可能成为两道真实防线。

协议可以把两个秘密正确组合。故障域是否也被分开，必须由组织自己证明。