Go 1.27 crypto/mldsa 如何生成 ML-DSA 密钥：FIPS 204 与签名接口边界

如果 Go 服务需要为消息做抗量子签名，Go 1.27 已经可以直接从标准库的 crypto/mldsa 开始。最小路径不是先改 TLS，而是先固定参数集、生成密钥、签名，再用编码后的公钥完成一次验签；这样能把算法接口和业务协议分开核对。

crypto/mldsa 解决什么问题，先固定哪一个参数集

crypto/mldsa 实现的是 NIST FIPS 204 规定的 ML-DSA 后量子签名方案，包版本随 Go 1.27.0 发布。它提供 MLDSA44()、MLDSA65() 和 MLDSA87() 三组参数，分别对应不同的密钥与签名尺寸。官方文档建议多数应用先使用 ML-DSA-44；除非协议或合规要求已经明确指定更高参数集，不要在业务层随意切换。

这篇只处理签名对象的最小边界：私钥留在签名端，公钥编码给验签端，消息和 Context 由双方按协议约定。它不是把 ML-DSA 直接替换进所有现有证书链的迁移指南，证书、密钥轮换和协议协商仍需要单独设计。

最小配方：GenerateKey、Sign 和 Verify 如何接起来

密钥生成只需要一个参数集。签名端调用 PrivateKey.Sign，验签端用 NewPublicKey 从公钥编码恢复对象，再调用包级 Verify。下面的代码是一个可放进接口适配层的最小片段，省略了网络传输和持久化。

package main

import (
    "crypto/mldsa"
    "fmt"
)

func main() {
    sk, err := mldsa.GenerateKey(mldsa.MLDSA44())
    if err != nil {
        panic(err)
    }

    message := []byte("order:20260901")
    opts := &mldsa.Options{Context: "order-signature"}
    signature, err := sk.Sign(nil, message, opts)
    if err != nil {
        panic(err)
    }

    publicEncoding := sk.PublicKey().Bytes()
    pk, err := mldsa.NewPublicKey(mldsa.MLDSA44(), publicEncoding)
    if err != nil {
        panic(err)
    }
    if err := mldsa.Verify(pk, message, signature, opts); err != nil {
        panic(err)
    }
    fmt.Println("signature verified")
}

这里的 nil reader 不是遗漏：ML-DSA 的 Sign 方法会忽略 io.Reader 参数。真正需要保存的协议字段是参数集、公钥编码、消息摘要或原文约定、签名值和 Context；验签时任意一个字段不一致，都应该视为验签失败。

Context 和三组参数怎么形成稳定接口

Options.Context 用来区分不同用途的签名，例如把“订单确认”和“设备注册”分成两条域。它最多 255 字节，签名与验签必须使用完全相同的字符串；如果不需要域隔离，可以传 nil，此时等价于零值 Options。Context 应当由协议常量或版本化配置提供，不要把用户输入未经约束地拼进去。

表中的尺寸来自 crypto/mldsa 文档，适合拿来估算数据库字段、消息队列和 HTTP 头之外的载荷空间。它们不是安全等级的替代说明，也不能单独决定业务方案。

兼容坑：编译成功不代表 FIPS 模块下可以调用

官方文档特别说明：使用 FIPS 140-3 Go Cryptographic Module v1.0.0 时，GenerateKey、NewPrivateKey、NewPublicKey 和 Verify 会返回错误；v1.26.0 或更高版本的模块才提供该能力。因此部署前要把模块版本、运行模式和错误处理一起核对，而不是只在普通 Go 1.27 环境里检查导入是否成功。

另一个容易忽略的边界是私钥导出。PrivateKey.Bytes() 返回的是用于还原私钥的种子，不是可以随手写入日志的摘要；生产代码应把它交给专门的密钥存储或硬件边界，并限制复制、序列化和错误输出。公钥则可以通过 PublicKey.Bytes() 编码传输，但恢复时必须使用同一个参数集。

完整核对清单：把签名接口放进业务前看这六项

• Go 版本是否为 1.27 或更高，运行环境的 FIPS 模块版本是否满足要求。
• 协议是否明确写出 ML-DSA 参数集，不能让发送端和接收端各自默认。
• Context 是否固定、可追踪且不超过 255 字节，签名和验签是否完全一致。
• 公钥编码、消息字节序列和签名值是否都有明确的传输编码。
• 所有生成、解析、签名和验签错误是否都会被调用方处理。
• 私钥种子是否避开日志、监控标签、异常信息和普通业务表。

常见问题

ML-DSA-44、65、87 应该怎么选？

多数应用先从 ML-DSA-44 做接口和载荷评估；只有协议、合规或安全方案明确要求时再选 65 或 87。

签名时可以传入随机数 reader 吗？

可以按 crypto.Signer 形态传入，但 PrivateKey.Sign 会忽略这个 reader；不要把它当成业务侧的额外随机源。

Context 不同但消息相同，能验签通过吗？

不能。Context 是签名用途的一部分，签名端和验签端必须使用同一个值。

crypto/mldsa 能直接替代现有 TLS 证书吗？

不能直接这样判断。它提供签名对象和验签接口，证书链、协议协商和对端能力仍需按实际 TLS 方案单独核对。