Go crypto/mldsa ML-DSA 签名验证失败怎样定位公钥类型

定位 ML-DSA 验签失败时，先确认解析得到的动态类型是不是 *mldsa.PublicKey，再检查消息、签名和上下文。PKIX 解析成功只代表公钥结构可识别，不代表它一定属于 ML-DSA；如果读到的是 RSA 或 ECDSA 公钥，错误就发生在算法选择层，还没进入正确的验签路径。

Go 官方地址：https://go.dev/。下面以“对接方交付一个 PUBLIC KEY PEM 和一份签名”为原创示例场景，依据 Go 1.27.3 官方接口说明排查，不声称发生过真实事故。示例未在本文环境执行。

公钥类型检查解决的是哪一层问题

把所有失败都包装成“签名无效”，会隐藏输入格式、解析器和算法选择之间的差别。更实用的边界是：PEM 是否符合入口约定、DER 是否能按 PKIX 解析、返回类型是否符合预期，最后才判断 ML-DSA 的签名关系。

支持范围要写到版本与密钥封装

本文使用标准库 crypto/mldsa 的 PublicKey 和 Verify。PKIX 的 SubjectPublicKeyInfo、证书以及裸公钥编码不是同一种输入。PUBLIC KEY PEM 中通常包装 PKIX DER；证书应使用证书解析入口，而不是把整个 CERTIFICATE 的 DER 塞给 ParsePKIXPublicKey。

官方文档还说明了 Go 密码模块版本的可用性限制：使用 FIPS 140-3 Go 密码模块 v1.0.0 时，若干 ML-DSA 操作会返回错误；v1.26.0 或更新模块可用。这里是模块版本条件，不应与应用采用的 Go 工具链版本混为一谈，更不能据此代替组织自己的合规判断。

最小入口：解析后再进行安全类型断言

下面函数有意只支持单个 PUBLIC KEY PEM。message 和 signature 都应是传输层已经解码完成的字节；contextName 是协议指定的签名上下文，不是 Go 的 context.Context。公钥必须已通过可信渠道获得，函数本身不完成身份授权。

package signature

import (
    "bytes"
    "crypto/mldsa"
    "crypto/x509"
    "encoding/pem"
    "errors"
    "fmt"
)

// VerifyPublicPEM 仅接收单个 PKIX PUBLIC KEY，不把证书或原始公钥混入此入口。
func VerifyPublicPEM(keyPEM, message, signature []byte, contextName string) error {
    block, rest := pem.Decode(keyPEM)
    if block == nil || block.Type != "PUBLIC KEY" {
        return errors.New("需要 PUBLIC KEY 类型的 PEM 公钥")
    }
    if len(bytes.TrimSpace(rest)) != 0 {
        return errors.New("不接受公钥后的额外内容")
    }
    parsed, err := x509.ParsePKIXPublicKey(block.Bytes)
    if err != nil {
        return fmt.Errorf("解析 PKIX 公钥失败: %w", err)
    }
    publicKey, ok := parsed.(*mldsa.PublicKey)
    if !ok {
        // 类型可用于内部诊断，不打印完整密钥和消息。
        return fmt.Errorf("公钥算法不匹配，实际类型为 %T", parsed)
    }
    if len(contextName) > 255 {
        return errors.New("签名上下文不能超过255字节")
    }
    // 签名和验签必须使用同一消息字节及同一上下文。
    if err := mldsa.Verify(publicKey, message, signature,
        &mldsa.Options{Context: contextName}); err != nil {
        return fmt.Errorf("ML-DSA 验签失败: %w", err)
    }
    return nil
}

这里使用带 ok 的类型断言，不让错误的密钥类型导致 panic。%T 只用于受控内部诊断，便于看出实际载入了什么算法。不要记录私钥、完整业务消息或无必要的请求正文；对外接口可以返回统一错误，内部保留阶段分类。

函数要求 PEM 后没有其他非空白内容，以避免调用方误以为一串材料都被处理了。这个限制属于示例入口策略，不是声称所有合法 PEM 文件只能有一个块。若业务确需多密钥，应建立明确的逐项选择规则，而不是静默使用第一个能解析的块。

跨语言对接时，先对齐封装再对齐参数

如果对方给的是原始 ML-DSA 公钥，应明确参数集合，再使用 mldsa.NewPublicKey 的对应入口；不要把原始字节伪装成 PKIX。参数集合可由 PublicKey.Parameters 获取，用于与协议的 ML-DSA-44、65 或 87 约定比较。都属于 *mldsa.PublicKey，不意味着使用相同参数或相同密钥。

若从证书中取得公钥，证书的签名算法与证书所载公钥算法也不能混同。仅解析证书并取出 PublicKey，不等于完成证书链、有效期、身份和用途验证；这些必须按实际信任方案另外处理。

类型正确后，再看消息与信任边界

先确认同一份消息字节：文本换行、字符编码、JSON 重排或前后空格都可能改变签名输入。协议若传输 Base64，应先按约定解码一次，不要把 Base64 文本本身当成签名字节，也不要重复解码。不要随意预先哈希消息后再交给普通消息验签入口；输入形式必须与签名侧约定一致。

mldsa.Options.Context 在签名和验签两端必须一致，并且长度以字节计算，上限为 255；空值也属于协议选择。它用于区分签名用途，不会自动从请求路径、证书或消息中推导。排查时应记录采用了哪个上下文约定，而不是靠尝试多个上下文直到某个通过。

• 确认类型：是否为 *mldsa.PublicKey，而不是其他算法公钥。
• 确认身份：是否为这个签名者、这个密钥版本所对应的可信公钥。
• 确认参数：算法参数集合与对接约定相符。
• 确认字节：消息、签名和上下文未被传输层改写。
• 确认错误被处理：失败时不继续执行依赖签名授权的动作。

类型断言通过，就能证明签名者可信吗？

不能。类型只证明对象属于该 API 类型。信任仍依赖预先批准的密钥来源、密钥标识和轮换策略；攻击者提供的公钥不能因为能够验过它自己生成的签名就被授予身份。

不兼容时可以自动换另一种算法吗？

不应让不可信输入触发随意降级。保持明确的算法白名单和协议版本，无法解析或不符合参数约定时返回错误，再通过受控配置完成兼容迁移。

结论是先把密钥类型问题从签名问题中剥离。格式、动态类型和参数都符合预期后，再检查消息与上下文；最终成功仍只是一项密码学检查，不等同于整个身份和授权流程完成。

参考：Go ML-DSA API、PKIX 公钥解析及返回类型。