Go crypto/rsa EncryptOAEPWithOptions 怎样匹配跨语言 MGF1 参数

Go 端 RSA-OAEP 密文无法被 Java、OpenSSL 或硬件服务解开时，先别急着换密钥。最常见的原因是 OAEP 的主哈希、MGF1 哈希、label 或密钥模长没有形成同一组参数。Go 1.26 起，可以用 EncryptOAEPWithOptions 单独指定主哈希和 MGF1 哈希，正好覆盖此前加密端只能传一个 hash 的互操作限制。

官方资料：https://pkg.go.dev/crypto/rsa

先把 OAEP 参数当成一份互操作契约

RSA-OAEP 不是“选一个 SHA-256 就结束”。至少要记录四项：OAEP 主哈希 Hash、MGF1 哈希 MGFHash、label，以及 RSA 密钥尺寸。主哈希决定标签摘要和编码结构中的摘要长度；MGF1 哈希参与掩码生成；label 虽然不加密，却会参与校验；密钥尺寸则决定明文上限与密文固定长度。

例如对端约定“SHA-256 做 OAEP，SHA-1 做 MGF1，label 为空”，Go 侧不能只把 sha256.New() 传给旧的 EncryptOAEP，因为那会让 MGF1 也跟着使用同一个哈希。

用 EncryptOAEPWithOptions 固定主哈希与 MGF1

Go 1.26 提供了带选项的加密入口。下面的示例只展示参数契约和错误处理；代码中的密钥由调用方已有的 RSA 公钥提供，不能把示例中的参数理解成任何特定厂商的默认值。

package main

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

func encryptForPeer(pub *rsa.PublicKey, plaintext, label []byte) ([]byte, error) {
    // 主哈希和 MGF1 哈希按对端协议分别填写；这里模拟 SHA-256 + SHA-1。
    opts := &rsa.OAEPOptions{
        Hash:    crypto.SHA256,
        MGFHash: crypto.SHA1,
        Label:   label,
    }
    // 让对应哈希实现进入链接结果，避免 Available() 为 false。
    _ = sha256.New
    _ = sha1.New
    ciphertext, err := rsa.EncryptOAEPWithOptions(rand.Reader, pub, plaintext, opts)
    if err != nil {
        // 不吞掉密钥尺寸、哈希不可用或参数不匹配等执行错误。
        return nil, fmt.Errorf("RSA-OAEP 加密失败: %w", err)
    }
    return ciphertext, nil
}

示例里的两个哈希导入是为了让代码意图清楚：标准库会根据 crypto.Hash 查找实现，实际项目应按工具链和依赖方式确认对应包已链接。若协议规定 Hash 与 MGF1 相同，可以让 MGFHash 保持零值，但跨语言场景最好显式记录最终采用的算法。

跨语言解密失败时按同一顺序排查

第一步比对参数表，而不是只看错误字符串。Go 的 RSA 解密错误通常是故意泛化的 crypto/rsa: decryption error，它可能由错误的密钥、OAEP 参数、label、截断或损坏的密文共同触发。

第二步检查密文是否完整。RSA-OAEP 密文长度应等于 RSA 模数的字节长度；Base64 解码时混用 URL 字母表、去掉填充或把字符串当作十六进制，都会让同一密文在传输后变形。

第三步做本地回环：用同一公私钥、同一 Hash、MGFHash、label 加密后解密。如果回环成功而对端失败，问题通常落在跨语言参数或编码边界；如果回环也失败，再检查哈希实现、密钥尺寸和明文长度。

• Java 的 OAEP transformation 名称不一定完整表达 MGF1 哈希，需读取实际 OAEPParameterSpec。
• OpenSSL 命令或 API 可能分别设置 OAEP digest、MGF1 digest 和 label，不能只看摘要名称。
• label 必须按字节比较；中文 label 的字符编码不能由两端各自默认推断。
• 明文过长和参数不一致是两类问题，先计算模长上限再判断。

版本兼容与可复用检查清单

EncryptOAEPWithOptions 属于 Go 1.26 的新增能力。若项目仍需支持旧工具链，不能把这个函数名直接回移；应先确认对端是否允许 Hash 与 MGF1 使用相同算法，再选择旧 API，或者把加密职责交给能表达完整 OAEP 参数的兼容层。不要为了“让它先解开”改成弱化校验或跳过 OAEP。

上线前把下面四行放进协议文档和测试向量：Hash=...、MGFHash=...、Label=hex...、RSA key bits=...。再补一条固定明文和 Base64 编码规则，互操作排障就能从猜测变成逐项比对。

相关问题

MGFHash 不填写时会怎样？

按 Go 的选项语义，零值会复用 Hash；只有协议明确允许两者相同才适合省略，跨语言协议最好显式写入记录。

为什么同一份密文每次都不一样？

OAEP 使用随机种子，同样的明文和公钥通常会产生不同密文；这不影响解密，测试应验证解密结果而不是比较密文字符串。

label 为空和不传 label 是一回事吗？

只有当两端最终使用的字节串都为空时才等价。非空 label 必须在加密、解密和协议文档中保持完全一致。

能否只修改 Go 的 Hash 来兼容对端？

不能先验假定可以。先拿到对端实际的 OAEP 与 MGF1 参数，再决定 Hash、MGFHash、label 和密钥尺寸的组合。