Go crypto/mlkem 实战：后量子密钥交换别自己瞎拼协议

后量子密码这几年聊得越来越多，但落到后端工程里，最容易走偏的一句话就是：“我们是不是得自己搞一套后量子加密？”

先别急。Go 标准库里的 crypto/mlkem 提供的是 ML-KEM，也就是密钥封装机制，不是直接拿来加密业务数据的算法。你用它得到的是共享密钥，然后再把这个共享密钥交给成熟的密钥派生和对称加密流程。

这篇我按生产工程讲：crypto/mlkem 到底做什么，ML-KEM-768 怎么用，哪些地方千万别自造协议，以及怎么给内部系统做迁移评估。

ML-KEM 是什么，不是什么

ML-KEM 以前大家也会叫 Kyber，它是 NIST 标准化的后量子密钥封装机制。简单说，它解决的是双方如何建立一个共享密钥，让后续通信可以使用这个密钥继续派生会话密钥。

它不是签名算法，也不是文件加密算法，更不是你把一段 JSON 丢进去就能变密文的工具。如果你需要签名，要看签名算法；如果你需要加密大量数据，应该用 AEAD，比如 AES-GCM 或 ChaCha20-Poly1305，并且让密钥来自正确的 KDF。

Go 的 crypto/mlkem 包实现了 ML-KEM。官方文档也明确说，多数应用应该使用 ML-KEM-768 这个参数集。

先看最小流程

典型流程是三步：Alice 生成密钥对，把封装公钥给 Bob；Bob 用这个公钥封装出共享密钥和密文；Alice 用自己的私钥解封装同一个共享密钥。

dk, err := mlkem.GenerateKey768()
if err != nil {
    return err
}

encapsulationKey := dk.EncapsulationKey().Bytes()

// Bob 收到 encapsulationKey 后：
ek, err := mlkem.NewEncapsulationKey768(encapsulationKey)
if err != nil {
    return err
}
sharedKeyBob, ciphertext := ek.Encapsulate()

// Alice 收到 ciphertext 后：
sharedKeyAlice, err := dk.Decapsulate(ciphertext)
if err != nil {
    return err
}

最后 sharedKeyBob 和 sharedKeyAlice 应该一致。注意顺序：Encapsulate() 返回的是 sharedKey, ciphertext，别写反。

生产里别直接用 sharedKey 加密

拿到 sharedKey 后，不建议直接把它当成所有用途的万能密钥。更稳的做法是把它交给 HKDF 或协议里的密钥派生流程，按用途派生出不同密钥。

hkdf := hkdf.New(sha256.New, sharedKey, salt, []byte("app-session-v1"))
key := make([]byte, 32)
if _, err := io.ReadFull(hkdf, key); err != nil {
    return err
}

为什么要派生？因为同一份密钥材料不应该到处复用。加密、认证、不同方向的数据流、不同协议版本，最好有明确隔离。

不要自己设计完整握手协议

这点我说重一点：如果你的目标是给公网服务做安全通信，优先用成熟协议，比如 TLS。协议设计里有身份认证、重放保护、降级保护、密钥确认、转录哈希、错误处理，这些不是靠几行 mlkem 代码就能补齐的。

crypto/mlkem 更适合这些场景：

• 你在做内部协议评估，需要理解 KEM 的输入输出。
• 你在维护安全组件，需要和已有协议框架集成。
• 你要写测试工具、兼容性验证或迁移实验。
• 你要给团队讲清后量子密钥交换的工程边界。

它不适合让业务同学随手拼一个“加密通道”。安全协议不是越新越安全，越随手越危险。

ML-KEM-768 还是 1024

Go 标准库提供了 ML-KEM-768 和 ML-KEM-1024。多数应用先看 768，官方文档也是这么建议的。1024 参数更大，密钥和密文也更大，成本更高，是否需要取决于你的安全目标和协议要求。

我不建议团队内部靠感觉选参数。安全参数应该来自标准、合规要求、协议规范或者安全团队评估，而不是“数字大看起来更安全”。

密钥材料怎么保存

DecapsulationKey 是私钥，必须保密。EncapsulationKey 是公钥，可以发给对方。sharedKey 是会话密钥材料，也必须保密，且不要写日志。

如果你要持久化私钥，需要考虑密钥管理系统、权限控制、轮换、备份和审计。千万别把 dk.Bytes() 打到日志里，也别把它塞进普通配置文件。

还有一个很常见的坑：为了调试，把共享密钥 hex 打印出来。开发环境里看似方便，最后很容易被 CI 日志、错误报告、观测平台收走。安全材料默认不打印。

混合密钥交换更现实

真实迁移里，很多系统不会突然从传统 ECDH 直接切到纯 ML-KEM。更现实的是混合模式：传统密钥交换得到一份 secret，ML-KEM 得到一份 secret，再一起输入 KDF。

这样做的价值是，即使某一边未来被证明有问题，另一边仍然提供保护。当然，混合也不是随便拼接字符串就完事，应该遵循协议规范。

ikm := bytes.Join([][]byte{ecdhSecret, mlkemSecret}, nil)
hkdf := hkdf.New(sha256.New, ikm, transcriptHash, []byte("hybrid-v1"))

这里只是表达思路。真正在协议里落地，要把握手上下文、双方身份、算法协商结果都纳入密钥派生。

测试怎么写

随机封装每次都会产生不同密文，所以测试不要简单期待固定 ciphertext。你可以测这些性质：

• Bob 封装后的共享密钥，Alice 能正确解封装。
• 篡改 ciphertext 后，Decapsulate 返回错误。
• 错误长度的公钥或密文会被拒绝。
• 共享密钥长度符合预期。
• 密钥材料不会出现在日志输出里。

如果需要确定性测试，官方还提供了相关测试辅助包。业务测试里更重要的是测协议边界，而不是追求每个随机字节固定。

怎么引入老项目

如果你们现在用的是普通 TLS 服务，我的建议不是“马上自己接 mlkem”。先确认 Go 版本、TLS 栈、网关、客户端、合规要求，以及上游平台是否已经支持后量子混合密钥交换。

如果是内部私有协议，迁移顺序可以这样：

• 先做协议设计评审，不要直接写代码。
• 明确身份认证、重放保护、降级保护和密钥派生。
• 用测试环境做双端兼容性验证。
• 记录握手版本和算法协商结果。
• 灰度上线，并保留回滚路径。

后量子迁移不是一个函数替换，而是一条协议链路升级。

我的 review 清单

• 是否把 ML-KEM 当成密钥封装，而不是直接加密算法。
• 是否优先使用 ML-KEM-768，或者有明确理由选择 1024。
• 私钥和共享密钥是否没有进入日志、配置和错误信息。
• 共享密钥是否经过 KDF 派生后再使用。
• 是否有身份认证、重放保护和降级保护设计。
• 是否测试了错误公钥、错误密文和篡改密文。
• 是否避免业务层自己拼完整安全协议。

最后说句实在话

crypto/mlkem 是一个很重要的标准库能力，但它不是“后量子万能按钮”。它给你的是建立共享密钥的积木，而不是完整房子。

我的建议是：普通业务通信优先跟随成熟协议和平台升级；内部协议要引入 ML-KEM，先做设计评审，再写代码。别把安全迁移做成一次看起来很酷、实际没人敢审的自造协议。