让我们统一采用种子作为ML-KEM密钥
上周，NIST发布了ML-KEM1规范FIPS 203的最终版本。与草案相比，最终文档明确允许将私有解封装密钥作为种子存储。这是向密码学工程社区的呼吁：让我们统一仅使用种子作为ML-KEM密钥的存储格式，忘记扩展解封装密钥的序列化格式甚至存在。
种子具有多重优势。最明显的是大小：种子为64字节，而扩展解封装密钥根据ML-KEM参数集分别为1,632、2,400或3,168字节。
但更重要的是，64字节的种子始终有效，而扩展解封装密钥需要验证。FIPS 203第7.3节要求进行以下检查：
|
|
以确保输入密钥的两个部分一致：预计算的封装密钥哈希和封装密钥本身。
然而，这还不是全部。解封装密钥扩展格式为：
|
|
其中s和t是NTT元素的向量。NTT元素又是域元素的向量，域元素是0到3,329之间的数字，编码为16位整数。如果编码的域元素高于3,329怎么办？这是无效的！那么该怎么办？如果在封装密钥中发现这样的元素，FIPS 203第7.2节要求拒绝它。但是如果在作为解封装密钥一部分的封装密钥（t值）中发现呢？如果在解封装密钥的不同部分（s值）中发现呢？规范没有说明！
使用种子可以完全避免这些复杂问题，因为是由实现本身派生s、t和H(ekPKE)，因此可以确保它们是有效的。
好的，种子更小更简单，减少了错误空间，但是它们昂贵吗？并不昂贵，以至于在千兆链路上加载扩展解封装密钥的成本几乎与扩展种子相当，但最重要的是这并不重要！
密钥隐式有两种表示形式：一种在线路上传输，一种在内存中。后者可以包含预计算值以实现更快的操作，并且不需要固定的字节格式。从一种形式转换到另一种形式的成本——种子扩展的成本——对于私钥来说并不重要：要么密钥是短暂的，在这种情况下它们可以直接进入内存表示形式，要么它们被大量重用，在这种情况下反序列化成本会被分摊。
ML-KEM扩展解封装密钥格式实际上甚至不是一个好的内存格式，因为它不包含完整的扩展矩阵A，而是包含其种子ρ。这是一个奇怪的中间状态，其中一些值被扩展（因此需要验证它们），但其他一些值没有被扩展（因此需要扩展它们）。
种子具有明显的优势，并且规范明确允许使用它们，因此我们肯定会在实际应用中看到它们被使用。如果我们还支持扩展格式，我们将会遇到互操作性问题，并且必须承担两个代码路径的所有复杂性。我们最好不要这样做。
说到互操作性，FIPS 203在字节序列方面做得很好……除了种子，它被定义为(d, z)。我认为我见过的每个实现都只是通过将它们连接为64字节缓冲区来存储它们，因此希望我们都能就此达成一致。如果有人建议使用ASN.1 SEQUENCE of BIT STRINGs或其他什么，我会辞职。
为了真正解决这个问题，我们需要（越早越好！）一个像RFC 8410那样的规范，它指定密钥格式并为例如PKCS #8中的使用分配OID。有趣的是，RFC 8410用于Ed25519的OID弧1.3.101现在作为IANA注册表管理，策略为"Specification Required"，而不是"RFC Required"。参见RFC 8411。这意味着任何人都可以制作例如引用FIPS 203的C2SP文档，并为ML-KEM请求OID分配。除非已经有人在分配OID，否则这很可能是最快的路径，我们等待的时间越长，生态系统分裂的风险就越大。
编辑（发送后几分钟）：好吧，忽略所有这些，我的邮件列表收件箱晚了一天，我刚刚看到NIST已经为所有ML-KEM参数发布了OID，并链接到draft-ietf-lamps-kyber-certificates-03以获取密钥格式规范。该草案的"私钥格式"部分没有说明实际的私钥格式是什么，希望它最终会采用64字节种子。
具体来说，对于实现，我建议完全不实现扩展密钥解析和验证，或者将其降级为内部函数，如去随机化变体，不暴露在公共API中。这就是我在filippo.io/mlkem768中所做的，也可能是我们在Go标准库中要做的。我们还将确保CCTV和Wycheproof中的测试向量不需要它（即它们提供种子作为输入）。这将使测试需要畸形解封装密钥的问题变得困难或不可能，但这就是重点：如果你不暴露API，你不需要测试其失败情况。所有其他向量应该可以通过暴力破解种子来重现。
如果你读到这里，你可能还想在Bluesky上关注我@filippo.abyssdomain.expert或在Mastodon上关注我@filippo@abyssdomain.expert。