Go crypto/mldsa 怎样生成后量子签名密钥

在 Go 1.27 及以后，生成后量子签名密钥可以直接使用标准库 crypto/mldsa。最小写法是调用 mldsa.GenerateKey(mldsa.MLDSA44())；它返回内存中的私钥，再通过 PublicKey().Bytes() 导出公钥编码。官方地址：https://pkg.go.dev/crypto/mldsa。

先选对 ML-DSA 参数集

crypto/mldsa 实现 FIPS 204 规定的 ML-DSA 签名方案。标准库提供三个固定参数集，文档建议大多数应用从 MLDSA44() 开始；只有协议或安全评估明确要求时，再考虑 MLDSA65() 或 MLDSA87()。它们不是同一把密钥的三个模式，而是生成时就确定的参数集合。

这些尺寸是编码尺寸，不是安全等级的简单替代物。落地前还要确认对端、证书格式、传输字段和存储预算能容纳对应长度。

GenerateKey 生成密钥并导出公钥

生成阶段只需要给出参数集。下面的示例同时展示公钥导出和一次签名验证；示例里的打印值是由 API 语义推导出的长度说明，不代表本文已经执行过这段代码。

package main

import (
    "crypto/mldsa"
    "fmt"
    "log"
)

func main() {
    // MLDSA44 是多数应用的起点，GenerateKey 会随机生成新的私钥。
    sk, err := mldsa.GenerateKey(mldsa.MLDSA44())
    if err != nil {
        log.Fatal(err)
    }

    // 公钥编码可以交给验证方；私钥不能进入日志或普通配置文件。
    publicKey := sk.PublicKey().Bytes()
    message := []byte("release manifest")
    signature, err := sk.Sign(nil, message, &mldsa.Options{Context: "manifest-v1"})
    if err != nil {
        log.Fatal(err)
    }

    // 验证方按相同参数恢复公钥，并使用完全相同的上下文。
    pk, err := mldsa.NewPublicKey(mldsa.MLDSA44(), publicKey)
    if err != nil {
        log.Fatal(err)
    }
    if err := mldsa.Verify(pk, message, signature, &mldsa.Options{Context: "manifest-v1"}); err != nil {
        log.Fatal("signature is invalid: ", err)
    }
    fmt.Println(len(publicKey), len(signature))
}

Sign 的第一个参数是为兼容 crypto.Signer 保留的 reader，在这个 API 中会被忽略；直接传入消息时，opts 可以是带上下文的 *mldsa.Options。若验证时报错，先检查消息字节、公钥参数集和 context 是否逐项一致，不要只反复生成新密钥。

私钥恢复只保存 seed，不能混淆公钥编码

PrivateKey.Bytes() 返回的是私钥 seed，长度必须正好是 mldsa.PrivateKeySize，当前为 32 字节。它是高敏感密钥材料，应放入专用密钥存储或受保护的密钥文件；公钥则可以按协议公开。恢复时使用同一个参数集：

// seed 应来自受保护的密钥存储，示例只展示 API 关系，不写入真实密钥。
func restorePrivateKey(seed []byte) (*mldsa.PrivateKey, error) {
    // NewPrivateKey 要求 seed 恰好为 mldsa.PrivateKeySize 字节。
    return mldsa.NewPrivateKey(mldsa.MLDSA44(), seed)
}

// 公钥编码不是 seed，不能把 PublicKey().Bytes() 传给 NewPrivateKey。

参数集不匹配也不能靠类型转换解决：由 MLDSA44 派生的 seed 应使用 MLDSA44 恢复。不要把 seed、私钥编码和公钥编码混称为“密钥字符串”，否则很容易在配置迁移时写错字段。

上线前核对兼容与安全边界

第一，crypto/mldsa 是 Go 1.27 的新增标准库，旧工具链不能因为改了 import 就自动获得它。第二，官方文档说明在 FIPS 140-3 Go Cryptographic Module v1.0.0 模式下，GenerateKey、NewPrivateKey、NewPublicKey 和 Verify 会返回错误；部署环境若启用了该模式，必须先按合规方案确认是否允许使用。

第三，ML-DSA 签名和 ML-KEM 密钥交换不是同一件事：本文只讨论 crypto/mldsa 的签名密钥，不把它当作 TLS 密钥交换配置。Go 1.27 同时给 crypto/x509 和 TLS 1.3 增加了 ML-DSA 相关支持，但证书和握手接入仍需单独核对对端协议与证书链。

• 记录参数集，避免验证端默认值与签名端不同。
• 公钥、签名字段按最大编码尺寸设计，避免截断。
• context 用于区分用途，变更用途时显式版本化。
• 私钥 seed 不写日志、不进普通环境变量，也不与公钥字段共用配置名。

相关问题

MLDSA44、MLDSA65 和 MLDSA87 能互相验证吗？

不能把它们当成可互换模式。签名、验证、公钥恢复需要使用与密钥对应的参数集，协议字段也应记录这个选择。

context 不一致会发生什么？

验证不会把不同用途的签名当成同一用途的有效签名。签名端和验证端必须传入完全相同的 context，空 context 也应由协议明确约定。

能把 PrivateKey.Bytes 当成普通备份内容吗？

不能。它是 32 字节 seed，足以恢复私钥，应按私钥材料保护；需要备份时使用受控密钥存储，并记录参数集。