Go rsa.DecryptOAEP 怎么绑定 label 防止密文错用

可以，做法是让 rsa.EncryptOAEP 和 rsa.DecryptOAEP 使用完全相同的 label。label 不会作为明文附在密文里，却参与 OAEP 编码；如果订单密文被送到令牌解密入口，而两个入口使用不同 label，解密会失败。它适合绑定“业务用途、数据类型、协议版本”这类上下文，但不能代替签名、AEAD 或权限校验。

Go 标准库文档：https://pkg.go.dev/crypto/rsa

label 解决的是同一密钥下的用途混淆

一个服务常会复用同一把 RSA 公钥：订单服务加密会话密钥，令牌服务加密一次性凭据，配置服务加密小段秘密。如果各入口都把 label 留空，那么从接口设计上看，这些密文没有用途分区；某段密文被投递到错误入口时，只能依赖后续业务解析再发现问题。

OAEP 的 label 可以把用途约定提前放进解密条件。比如订单使用 orders:key:v1，令牌使用 tokens:credential:v1。密文仍由 RSA-OAEP 保护，但只有提供加密时同一 label 的解密调用才能成功。Go 官方文档明确要求：解密参数 label 必须和加密时传入的值一致。

最小写法：加密和解密必须使用同一个 label

下面把 label 定义成稳定常量。加密端使用 sha256.New()、公钥和 label；解密端使用同一种哈希、私钥和同一个 label。DecryptOAEP 的第二个 random 参数是历史遗留参数，当前文档说明它会被忽略，可以传 nil。

package oaepdemo

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

var orderLabel = []byte("acme:orders:key:v1")

func EncryptOrderKey(pub *rsa.PublicKey, plaintext []byte) ([]byte, error) {
    // OAEP 加密需要安全随机源；label 绑定密文的业务用途。
    ciphertext, err := rsa.EncryptOAEP(
        sha256.New(), rand.Reader, pub, plaintext, orderLabel,
    )
    if err != nil {
        return nil, fmt.Errorf("encrypt order key: %w", err)
    }
    return ciphertext, nil
}

func DecryptOrderKey(priv *rsa.PrivateKey, ciphertext []byte) ([]byte, error) {
    // 解密必须复用相同哈希和完全相同的 label；random 参数可传 nil。
    plaintext, err := rsa.DecryptOAEP(
        sha256.New(), nil, priv, ciphertext, orderLabel,
    )
    if err != nil {
        return nil, fmt.Errorf("decrypt order key: %w", err)
    }
    return plaintext, nil
}

这里的“相同”是字节级相同，而不是肉眼看起来接近。大小写、分隔符、空格、编码和版本号任何一处变化都会形成不同 label。不要让一端写 orders:key:v1，另一端临时拼成 order:key:v1。

把 label 设计成稳定协议字段

真正容易出错的不是 API 调用，而是 label 的生命周期。若业务方自由拼接字符串，重构服务名、切换大小写或改变字段顺序，都可能让历史密文突然无法解开。更稳妥的做法是把 label 当作协议常量：字段含义固定，编码固定，版本变化显式升级。

package oaepdemo

import "strings"

type Purpose string

const (
    PurposeOrderKey   Purpose = "orders:key"
    PurposeTokenValue Purpose = "tokens:credential"
)

func Label(p Purpose, version string) []byte {
    // 只允许受控枚举进入 label，避免把用户输入和敏感数据拼进协议字段。
    version = strings.TrimSpace(version)
    return []byte("acme:" + string(p) + ":" + version)
}

如果生产系统已有多语言客户端，还应在接口文档中写清 UTF-8 编码、分隔符、字段顺序和版本格式。不要依赖某种语言的结构体序列化结果，因为不同实现对字段排序、空值和转义的处理可能不同。最简单的常量字节串通常最容易跨语言复现。

版本升级也不要原地修改 v1 的含义。需要新的载荷约束时使用 v2，解密端在迁移期可以根据可信元数据选择允许的版本入口，但不能在一次失败后遍历所有 label 盲试，否则用途边界会被重新放宽。

label 不匹配时统一按解密失败处理

Go 的 rsa.ErrDecryption 故意保持模糊，以减少自适应攻击可利用的信息。应用层不要把“label 不匹配”“密文损坏”“私钥不对”分别回显给外部调用者。对外统一返回“密文不可解”，对内只记录请求标识、用途常量和错误类别，不记录私钥、明文或完整密文。

package oaepdemo

import (
    "crypto/rsa"
    "crypto/sha256"
    "errors"
)

var ErrInvalidCiphertext = errors.New("ciphertext cannot be decrypted")

func decryptForPurpose(
    priv *rsa.PrivateKey,
    ciphertext []byte,
    label []byte,
) ([]byte, error) {
    // 所有 OAEP 失败都收敛成统一业务错误，避免向调用方暴露失败细节。
    plaintext, err := rsa.DecryptOAEP(
        sha256.New(), nil, priv, ciphertext, label,
    )
    if err != nil {
        return nil, ErrInvalidCiphertext
    }
    return plaintext, nil
}

统一错误不等于不做观测。内部指标可以按“订单入口失败次数”“令牌入口失败次数”聚合，但不要把低层密码学差异直接回传。若错误突然集中出现，先核对发布版本、label 常量和哈希配置，再检查密钥轮换及消息路由。

封装用途专用入口，别让调用方自由拼 label

更稳妥的做法是把通用解密函数留在包内，只对业务暴露 DecryptOrderKeyV1、DecryptTokenCredentialV1 这类用途专用入口。这样调用者没有传入任意 label 的机会，代码审查也能直接看出密文将进入哪个用途边界。

package oaepdemo

import "crypto/rsa"

var (
    labelOrderV1 = []byte("acme:orders:key:v1")
    labelTokenV1 = []byte("acme:tokens:credential:v1")
)

func DecryptOrderKeyV1(priv *rsa.PrivateKey, ciphertext []byte) ([]byte, error) {
    // 订单入口固定订单 label，不接收调用方传入的用途字符串。
    return decryptForPurpose(priv, ciphertext, labelOrderV1)
}

func DecryptTokenCredentialV1(priv *rsa.PrivateKey, ciphertext []byte) ([]byte, error) {
    // 令牌入口固定令牌 label，避免订单密文被错误解释为凭据。
    return decryptForPurpose(priv, ciphertext, labelTokenV1)
}

如果系统通过队列传递密文，消息头里的用途字段只能用于选择入口，真正的约束仍由 OAEP label 完成。路由字段被误改时，错误入口会使用不同 label，解密失败；但如果攻击者能任意调用正确入口，label 本身不会替你完成授权，因此接口权限和调用身份仍需单独控制。

别忽略哈希、长度和真实性边界

哈希必须一致。 OAEP 由哈希函数参数化，同一密文的加解密必须使用同一种哈希。示例选择 sha256.New()；若一端使用 SHA-256，另一端改成其他哈希，即使 label 相同也无法解密。

RSA 只适合加密小消息。 官方文档给出的最大消息长度是公钥模数的字节长度减去两倍哈希长度，再减 2。更常见的工程方案是使用 RSA-OAEP 加密随机生成的对称密钥，再用 AES-GCM 等 AEAD 保护实际业务数据。

label 不是签名。 它能把 OAEP 密文绑定到一个上下文，却不证明谁创建了密文。Go 官方示例也提醒：加密只提供机密性；需要真实性时，应使用适当的签名或经认证的混合加密设计，并同时考虑消息重放和重排。

不要把 label 当秘密。 label 可以包含上下文，但不会被加密。用公开、稳定、低基数的协议标识即可，不要放访问令牌、邮箱、订单号或可识别个人的信息。

测试要覆盖“能解”和“必须不能解”

只测试正常解密是不够的。至少要覆盖同 label 成功、不同 label 失败、不同哈希失败、密文被修改失败，以及用途专用入口互换失败。测试应只判断成功或统一错误，不依赖底层错误文本。

package oaepdemo_test

import (
    "crypto/rand"
    "crypto/rsa"
    "testing"

    "example.com/oaepdemo"
)

func TestCiphertextCannotCrossPurpose(t *testing.T) {
    // 测试使用临时密钥；生产密钥应来自受控密钥管理系统。
    priv, err := rsa.GenerateKey(rand.Reader, 2048)
    if err != nil {
        t.Fatal(err)
    }

    ciphertext, err := oaepdemo.EncryptOrderKey(&priv.PublicKey, []byte("key-material"))
    if err != nil {
        t.Fatal(err)
    }

    // 同一订单入口应成功恢复明文。
    if _, err := oaepdemo.DecryptOrderKeyV1(priv, ciphertext); err != nil {
        t.Fatalf("order decrypt failed: %v", err)
    }

    // 令牌入口使用不同 label，必须拒绝订单密文。
    if _, err := oaepdemo.DecryptTokenCredentialV1(priv, ciphertext); err == nil {
        t.Fatal("cross-purpose ciphertext was accepted")
    }
}

若测试跨语言实现，再增加一组固定协议向量：记录哈希名称、label 的十六进制字节、密钥标识和预期成功或失败，不要只记录人类可读字符串。这样可以快速定位编码差异，而不会把“看起来相同”误认为字节相同。

上线前检查清单

• 加密端和解密端是否使用同一种 OAEP 哈希？
• label 是否由受控常量生成，而不是直接接受用户输入？
• 业务用途、数据类型和协议版本是否有稳定且唯一的组合？
• 旧版本 label 的含义是否保持不变，迁移期是否有明确截止策略？
• 外部错误是否统一，日志是否避免记录明文、私钥和完整密文？
• 是否测试了跨用途错投、密文篡改、哈希不一致和密钥不匹配？
• 真实性、授权和重放防护是否由签名、AEAD、身份鉴别及业务协议另行承担？

归纳起来，rsa.DecryptOAEP 绑定 label 的关键不是“传一个字符串”，而是把 label 当成双方共享的协议常量。加密与解密使用同一字节串，业务入口各自固定用途，错误统一处理，再用测试证明密文不能跨域，才能真正减少密文错用。

相关问题

label 可以为空吗？

可以。官方文档说明不需要上下文时可以为空。但如果同一公钥承担多个用途，明确区分 label 通常更有利于隔离密文域。

label 需要存进数据库吗？

通常不需要把它当秘密保存。更推荐由密文记录中的可信协议版本和业务类型选择固定常量；若要存储，也应存用途和版本标识，而不是让任意字符串直接进入解密函数。

label 不同能判断具体是哪一项不匹配吗？

不应依赖这种区分。对调用方统一视为解密失败，通过受控入口、部署版本和内部指标定位配置问题。

有了 label 还需要签名吗？

需要视协议而定。label 绑定上下文，但不提供发送者身份认证。需要证明来源或防篡改时，应采用经过审查的签名或经认证混合加密方案。