NSA 推动单一 ML - KEM，IETF 投票背后是不可原谅的安全灾难？

博客文章索引较早文章访问 - J提到一种简单的方法来比较单一 PQ 与 ECC PQ。目录中包含多篇文章如 2026.07.06 的“美国国家安全局NSA与互联网工程任务组IETF第 8 部分公平性”等涵盖了从 2014 年到 2026 年关于密码学、安全标准等多方面的内容。NSA 过往安全操作问题NSA 的秘密文件显示20 世纪 70 年代NSA 推动数据加密标准DES目的是“排挤竞争对手”且他们知道 DES“足够脆弱”可被破解同时却公开宣称会使用 DES。20 世纪 90 年代NSA 利用出口法律例外条款巩固 RC4 和 RSA - 512 的地位导致安全问题持续了数十年。21 世纪 00 年代NSA 破坏随机数生成器RNG标准并付钱给公司部署这些标准。到 21 世纪 10 年代NSA 每年有 2.5 亿美元的预算用于“秘密影响和/或公开利用”标准和其他系统使其“可被利用”而“消费者和其他对手”却认为“系统的安全性仍然完好”。IETF 关于单一 ML - KEM 的投票情况目前 IETF 传输层安全TLS工作组的投票在 IETF 的官腔中被称为“最后呼吁”此次投票是关于 NSA 公然推动的在 TLS 中采用单一机器学习密钥封装机制ML - KEM的 IETF 请求注释RFC。发布 RFC 意味着 IETF 认可在 TLS 中使用单一 ML - KEM。推测在 TLS 中针对单一 ML - KEM 和单一机器学习数字签名算法ML - DSA发布 RFC 之后NSA 将继续投入资金鼓励更广泛地部署单一 ML - KEM 和单一 ML - DSA这将是一场不可原谅的安全灾难因为可以预见 ML - KEM 软件和 ML - DSA 软件会出现大量漏洞更不用说规范本身存在安全缺陷的风险了。IETF 规则规定参与是“对所有人开放”的这次关于单一 ML - KEM 的投票称“于 2026 - 07 - 08 结束”但不清楚是否 8 号当天仍可提交投票以及所说的是哪个时区显然投票即将结束。IETF 还表示工作组的所有“正式工作”都在工作组的邮件列表上进行对于这次特定的投票邮件列表上出现了越来越多人的反对意见目前已有 60 人支持者们想尽各种理由来阻止反对人数的增加。支持者理由及反驳2026 年 7 月 1 日来自“ncsc.gov.uk”即 NSA 在英国的合作伙伴英国政府通信总部 GCHQ的“Michael P”称“对安全性的推测性声明”有“阻碍向 ML - KEM 迁移的潜在风险”。但去年 9 月ML - KEM 已占 Cloudflare HTTPS 连接的一半且是 ECC PQ不是单一 PQ所以指出安全问题不会减缓迁移。2026 年 7 月 3 日保罗·霍夫曼称投赞成票的理由是“可信的密码学界同时支持” ECC ML - KEM 和单一 ML - KEM。然而奥尔·邓克尔曼、彼得·古特曼、法比安娜·达·皮耶韦等知名人士在这次“最后呼吁”期间对单一 ML - KEM 提出了反对意见霍夫曼忽略了自己早期在 NSA 推动 TLS 扩展方面的角色且未披露从 NSA 获得的资金他声称这些人“不可信”令人质疑。2026 年 7 月 5 日凯文·米尔纳称“是否有关于纯 ML - KEM 的 RFC 几乎肯定不会影响他们的建议”但 CSE 的基根·达席尔瓦·巴尔博萨投赞成票的理由是“我们确实计划在网络中心的 TLS 指南中纳入纯 ML - KEM”CSE 的乔纳森·哈梅尔也回应并投了赞成票。投票操纵情况作者对论点和反驳论点图表进行了多次更新最近一次是在 2026 年 6 月 25 日。支持者们不断提出有缺陷的论点无视重要反对意见和 IETF 规则中规定的分歧解决方式用政治投票过程取而代之并且公然操纵投票出现了来自 NSA、GCHQ、思科、谷歌等人员的赞成票。投票风险分析当不确定在评估该规范的优点时哪一方正确时需要考虑风险。IETF 没有规则限制一份文件可以经历的“最后呼吁”次数这份特定的文件已经经历了三次“最后呼吁”。如果在“最后呼吁”之后工作组主席宣布对发布 RFC 达成“大致共识”文件会由互联网工程指导组IESG盖章通过并发布IESG 征求社区意见但无规则迫使拒绝该文件且 IESG 成员多为国防承包商和 NSA 终身雇员不太可能拒绝 NSA 推动的文件。如果工作组主席没有宣布达成“大致共识”规则也不阻止再次尝试。IETF 称参与者应运用最好的工程判断为整个互联网找到最佳解决方案分歧必须通过公开审查和讨论的过程来解决但实际情况并非如此更像是一个未解决分歧的投票过程这不是 IETF 应有的运作方式。所以当不确定投哪一票正确时投反对票是在要求支持者回到谈判桌前。