Go RSA-PSS 签名验签参数不匹配怎么办

Go 里 RSA-PSS 签名成功、验签却返回错误时，先不要怀疑公钥格式。最常见的兼容性原因是签名端和验签端没有共享同一组摘要与 PSS 参数：消息算出的 digest 不同、传入的 crypto.Hash 不同，或者 PSSOptions.SaltLength 没有统一。尤其要注意，VerifyPSS 会忽略 opts.Hash，验签使用的是它的 hash 参数。

我在接入外部签名服务时，最容易漏掉的就是“Hash 名称相同，但盐长度约定不同”。如果协议没有特殊要求，本文建议从 SHA-256 + PSSSaltLengthEqualsHash 开始；如果外部协议明确规定盐长度，就把字节数写死在双方配置里。这样排查范围会比反复更换密钥小很多。

Go 官方标准库地址：https://pkg.go.dev/crypto/rsa

Hash 类型说明：https://pkg.go.dev/crypto#Hash

三个参数必须先对齐

RSA-PSS 的验签输入可以拆成三组：原始消息经过某个 Hash 得到的摘要、调用 API 时传入的 Hash 标识，以及 PSS 盐长度。摘要字节和 Hash 标识必须相互对应；盐长度则参与 PSS 编码。公钥只是验证签名的材料，不能替代这些参数约定。

Go 文档对 SignPSS 的说明是：digest 必须由传入的 Hash 算出；如果 opts.Hash 非零，它会覆盖 SignPSS 的 hash 参数。对 VerifyPSS 来说，opts.Hash 会被忽略，调用方必须把正确的 Hash 传进第二个参数。

先固定 SHA-256，再固定等 Hash 盐长

下面的示例把摘要计算和 PSS 参数放在同一个函数边界里，避免签名端改了 Hash 却忘记同步摘要。PSSSaltLengthEqualsHash 表示盐长度等于所用 Hash 的摘要长度；使用 SHA-256 时就是 32 字节。

package main

import (
    "crypto"
    "crypto/rand"
    "crypto/rsa"
    "crypto/sha256"
    "fmt"
)

// SignAndVerify 使用同一组摘要和 PSS 盐长完成签名与验签。
func SignAndVerify(priv *rsa.PrivateKey, message []byte) error {
    hashID := crypto.SHA256
    if !hashID.Available() {
        return fmt.Errorf("SHA-256 未链接到当前二进制")
    }

    // digest 必须由同一个 Hash 计算，不能只改 hashID 而继续复用旧摘要。
    digest := sha256.Sum256(message)
    opts := &rsa.PSSOptions{
        SaltLength: rsa.PSSSaltLengthEqualsHash,
    }

    signature, err := rsa.SignPSS(rand.Reader, priv, hashID, digest[:], opts)
    if err != nil {
        return fmt.Errorf("RSA-PSS 签名失败: %w", err)
    }

    // VerifyPSS 的 hash 参数决定验签使用的 Hash；opts.Hash 在这里不会生效。
    if err := rsa.VerifyPSS(&priv.PublicKey, hashID, digest[:], signature, opts); err != nil {
        return fmt.Errorf("RSA-PSS 验签失败: %w", err)
    }
    return nil
}

func main() {
    // 2048 位密钥仅用于示例；生产代码应从受保护的密钥来源读取。
    priv, err := rsa.GenerateKey(rand.Reader, 2048)
    if err != nil {
        panic(err)
    }
    if err := SignAndVerify(priv, []byte("订单摘要")); err != nil {
        panic(err)
    }
    fmt.Println("signature parameters are aligned")
}

这里有两个故意的约束：digest 和 hashID 在同一段代码里生成，opts 同时传给签名与验签。实际项目可以把它们拆成两个服务，但协议配置必须保留这三个值，而不是只记录“算法是 RSA-PSS”。

Hash 不一致时，为什么只改 opts.Hash 没用

假设签名端使用 sha256.Sum256，验签端却重新用 SHA-512 计算摘要，即使验签的 PSSOptions 写了 Hash: crypto.SHA256，也不能把已经传入的 SHA-512 摘要变成 SHA-256。更直接的写法是让验签端从协议配置选择 Hash，并用同一个配置计算 digest：

// DigestForPSS 返回与 hashID 对应的摘要，避免摘要和标识错配。
func DigestForPSS(hashID crypto.Hash, message []byte) ([]byte, error) {
    if !hashID.Available() {
        return nil, fmt.Errorf("Hash 未链接: %v", hashID)
    }
    h := hashID.New()
    // 写入失败在标准 Hash 实现中通常不会发生，但仍保留错误处理边界。
    if _, err := h.Write(message); err != nil {
        return nil, fmt.Errorf("计算摘要失败: %w", err)
    }
    return h.Sum(nil), nil
}

// VerifyConfiguredSignature 让协议 Hash 参与摘要计算和验签调用。
func VerifyConfiguredSignature(pub *rsa.PublicKey, hashID crypto.Hash, message, sig []byte) error {
    digest, err := DigestForPSS(hashID, message)
    if err != nil {
        return err
    }
    // 盐长策略仍由协议决定；这里只示范等 Hash 的默认契约。
    opts := &rsa.PSSOptions{SaltLength: rsa.PSSSaltLengthEqualsHash}
    return rsa.VerifyPSS(pub, hashID, digest, sig, opts)
}

Hash.New 只能在 Hash 已链接时使用，因此在动态选择算法时先检查 Available。对固定 SHA-256 的项目，直接使用 sha256.Sum256 更容易读；对协议兼容层，统一的 DigestForPSS 可以减少“枚举值改了、摘要实现没改”的错误。

固定盐长与自动盐长怎么选

Go 提供两类常用策略。PSSSaltLengthEqualsHash 把盐长固定为摘要长度；也可以把 SaltLength 设置成正整数，明确规定固定字节数。PSSSaltLengthAuto 在签名时让盐尽可能长，在验签时自动检测。自动策略在 Go 内部可以方便地配合，但跨语言时未必符合对方库的默认值。

如果对方文档只写“RSA-PSS with SHA-256”，这还不够作为互操作协议。需要继续确认 MGF1 Hash、盐长度、签名编码以及消息是直接 Hash 还是接收已经计算好的 digest。本文只聚焦 Go 的 Hash 和盐长两个边界，其他协议字段不能假设默认值相同。

按错误现象缩小排查范围

RSA-PSS 验签失败时，建议按下面的顺序记录输入，而不是先换一把密钥。错误信息通常是刻意模糊的验证错误，真正有用的是双方对协议字段的逐项比对。

签名函数返回 ErrMessageTooLong 时，盐长确实可能是原因之一；这和验签失败不是同一层问题。验签失败还要检查消息是否被编码、换行或字符集转换过。只要 digest 不同，盐长调得再准确也不会成功。

把参数写成协议，而不是散落在调用点

在项目里，我会把 RSA-PSS 的约定写成不可变配置或测试向量：hash=SHA-256、salt_length=32、mgf1_hash=SHA-256，并记录签名输入的字节编码。调用代码只接收已经解析的配置，避免一个服务用 Auto、另一个服务用等 Hash。

如果使用 crypto.Signer 接口而不是直接调用 SignPSS，还要注意 PSSOptions.Hash 是指定 Hash 的方式。这里不能把直接调用 VerifyPSS 的规则套过来；应按实际实现的接口契约写测试。

最小互操作测试至少包含：同一消息由 Go 签名、Go 验签；固定测试向量由外部实现签名、Go 验签；Go 签名、外部实现验签。每条向量都固定公钥、消息字节、Hash、盐长度和签名编码。测试通过后，再把它们作为协议变更的回归样本。

为什么签名每次得到的字节可能不同

PSS 签名包含随机盐。同一消息、同一密钥和同一盐长下，随机源不同也可能得到不同签名；验签不要求签名字节可重复，只要求参数和结果符合协议。

能不能验签时把 SaltLength 留成零值

零值对应 PSSSaltLengthAuto。它不是“忽略盐长约定”，而是选择自动策略。若协议要求固定盐长，应显式写等 Hash 或正整数，避免以后更换实现时默认行为变化。

只要 Hash 一样，盐长度不同也能验签吗

不能这样假设。Hash 和盐长都参与 PSS 参数；除非验签策略明确允许自动识别并且签名格式符合实现要求，否则应把盐长当作协议字段同步。

这类问题最后应收敛为一张参数表：消息字节怎样得到、Hash 用哪个枚举、摘要是否由该 Hash 计算、盐长是等 Hash、固定字节还是自动策略。把这四项和签名编码一起写进协议，通常比在验签失败后反复改调用顺序更有效。