摘要

  • RFC 10042 注册了三种 SSH 方法，把 ML-KEM 分别与 P-256、P-384 或 X25519 结合，并从两个结果导出一个共享秘密。
  • 二进制文件包含算法并不能证明它被使用；迁移证据必须来自每条连接的协商结果、失败原因和认证状态。

两种算法，一个协商方法

RFC 10042 针对“现在收集、以后解密”的风险，定义了 mlkem768nistp256-sha256、mlkem1024nistp384-sha384 和 mlkem768x25519-sha256。每个名称在 SSH 中都是一种方法，但内部同时运行传统 ECDH 与 ML-KEM 封装。

客户端发送拼接后的后量子与传统公开材料；服务器返回 ML-KEM 密文、传统公钥、主机密钥以及交换签名。双方必须检查预期长度，规定的校验或解封装失败会终止密钥交换。两个组成秘密按 K = HASH(K_PQ || K_CL) 合并，并以固定长度编码进入 SSH 密钥派生。

以上是规范事实。运维推断则是：只有混合方法在协商中胜出并完整执行，系统才跨过迁移边界。即使代码已部署，旧策略、版本差异或回退设置仍可能让会话选择传统方法。

混合交换不会替代认证

服务器主机密钥及其签名仍在交换记录中。混合密钥交换不能修复薄弱的主机密钥管理、未经核验的信任决定或被盗凭据。RFC 发布也不证明任何厂商或运营者已经部署。

RFC 要求每条连接都生成新的 ECDH 与 ML-KEM 临时密钥对，并禁止重复使用生成 ML-KEM 密文的随机数。它还规定固定长度秘密编码，以减少可变长度行为带来的时序泄漏风险。这些都把实现质量和随机数质量纳入控制面。

报文有边界，运营成本并非为零

三种方法都落在 SSH 最低报文尺寸能力以内，但团队仍需测试兼容性、CPU、时延、容量余量、失败遥测和回滚条件。一手来源没有量化任何具体环境的成本。

受益者是那些机密性需要跨越当前经典密码假设寿命的会话。成本由维护客户端、服务器、堡垒机、自动化和密码库的团队承担。只用传统交换更简单、兼容性更广，但没有 ML-KEM 组成部分；只用后量子算法会失去传统方案的对冲，也不是本 RFC 的设计。

来源