NSA试图推动ML-KEM单一加密标准化，引加密标准弱化争议

## 背景

NSA的SIGINT Enabling Project（信号情报赋能项目）长期以来包括破坏加密标准的过程。该项目由NSA资助并参与，与互联网公司合作，通过插入后门、修改商用软件等方式削弱加密保护。NSA曾公开承诺参与加密标准制定，但同时利用这些标准获取情报优势。

如今，NSA正公开出资推动对“ietf-tls-mlkem”（ML-KEM在TLS 1.3中的纯后量子密钥交换协议）的标准化。这一提案被视为对更合理的“ietf-tls-ecdhe-mlkem”（ML-KEM与传统椭圆曲线Diffie-Hellman混合协议）的削弱。混合协议能提供组成安全性：只要至少一个组件未被攻破，整体仍安全。

在反对意见出现后，NSA的支持者从“NSA要求如此，因此应标准化”的直言立场转向伪技术性辩护。例如，声称纯ML-KEM更高效、兼容性更好或符合某些分析。辩论图表和支持者近期论点摘要已在相关博客公开。

NSA此前在IETF TLS工作组的最新ML-KEM投票中失利（多数人反对）。然而，2026年6月24日，他们重新发起投票并开始“填充房间”。例如，2026年6月25日，NSA的Mike Jenkins投出赞成票。Jenkins此前从未在工作组邮件列表中出现过。此举符合IETF规则：“IETF没有成员身份”“任何人可通过注册工作组邮件列表参与”。

## 核心内容

2026年6月24日，IETF TLS工作组启动对draft-ietf-tls-mlkem-08的最后一次审查（Last Call），截止日期为2026年7月8日。提案定义了ML-KEM-512、ML-KEM-768和ML-KEM-1024作为TLS 1.3的NamedGroup（支持组），允许在TLS握手中直接使用纯ML-KEM作为密钥交换机制（无需椭圆曲线）。

提案关键机制：

• 协商：在supported_groups扩展中发送ML-KEM参数组ID（0x0200、0x0201、0x0202）。
• 传输：客户端发送ML-KEM公钥（encapsulation key）；服务器发送ML-KEM密文（ciphertext）。长度固定，与FIPS 203一致。服务器对客户端公钥进行FIPS 203的封装密钥检查，失败则发送illegal_parameter警报；客户端校验密文长度。
• 共享密钥计算：ML-KEM的Encaps/Decaps输出与TLS 1.3密钥调度直接兼容，替换（EC）DHE共享密钥。实现不得重用随机性，失败则发送internal_error警报。
• 安全考虑：提案引用多项形式化分析，称ML-KEM的IND-CCA安全满足TLS要求；支持纯KEM替换DHE。承认混合模式（如ietf-tls-ecdhe-mlkem）提供更强的组合安全性，但仍鼓励评估纯ML-KEM与混合模式的权衡。IANA登记要求Recommended列为N（非推荐）。

提案基于NIST FIPS 203，并强调在side-channel攻击下需谨慎实现。草案2026年6月24日更新，作者Deirdre Connolly（SandboxAQ）。

对比提案：ietf-tls-ecdhe-mlkem（草案-05）定义了X25519MLKEM768、SecP256r1MLKEM768、SecP384r1MLKEM1024混合组。客户端/服务器共享密钥为传统ECDHE部分与ML-KEM部分拼接。提案强调混合能同时抵御经典和量子攻击，并符合NIST SP 800-56A等FIPS标准。草案已提交IESG准备发布（Proposed Standard）。

NSA失去上一次投票后，于2026年6月24日再次发起投票并推动纯ML-KEM标准化，引发社区强烈反对。

## 关键要点

• NSA的SIGINT Enabling Project长期参与加密标准破坏，当前正公开资助纯ML-KEM协议（ietf-tls-mlkem），此协议被视为对更优混合协议（ietf-tls-ecdhe-mlkem）的削弱。
• 反对意见涌现后，支持者转向伪技术辩护；提案因安全评估不足而未获上次投票通过。
• 2026年6月24日重新投票并“填充房间”：Mike Jenkins（NSA人员）在6月25日投出首次邮件列表未曾出现的赞成票，符合IETF“无成员”规则。
• 提案草案（draft-ietf-tls-mlkem-08）定义ML-KEM-512/768/1024为TLS NamedGroup，允许纯KEM密钥交换，声称IND-CCA安全且兼容TLS 1.3密钥调度，但IANA Recommended列为N，并承认混合模式优势。
• 混合协议ietf-tls-ecdhe-mlkem提供组成安全性（任一组件破则协议不破），提案未充分解决这一点。
• 截止日期为2026年7月8日，需在TLS邮件列表（[email protected]）发送反对意见（主题“Re: [TLS] WG Last Call: draft-ietf-tls-mlkem-08”），使用真实姓名。
• 截至2026年7月1日，已有30余条反对邮件；示例包括Christian Grothoff、Tanja Lange等知名密码学家。

## 意义与影响

此事件暴露IETF标准化过程中利益相关方（如NSA）可能通过外部投票和资源投入影响结果，威胁全球互联网关键基础设施的安全。纯ML-KEM虽能在计算上更简洁，但混合模式能提供额外防御层（量子或经典攻击），提案的“可行性”辩护被批评为忽略组合安全模型。社区已发起超过30条正式反对，表明技术共识并未形成。

行动呼吁简明直接：任何IETF TLS参与者（注册邮件列表即可）均可于7月7日前提交反对，强调真实姓名以防止滥用匿名账号。成功若遭忽视，将削弱TLS 1.3中后量子密钥交换的可靠基础，影响全球HTTPS部署、数据传输和云安全。

更广泛而言，此案凸显后量子密码标准化需警惕“国家安全”借口下的技术妥协。IETF传统依赖开放讨论和形式化安全分析，若纯ML-KEM获通过，将降低协议对未来攻击的弹性，迫使企业自行选择混合模式，增加部署复杂性。建议读者密切关注邮件列表讨论，并考虑采用ietf-tls-ecdhe-mlkem以确保长期安全。