Go cipher.NewGCMWithTagSize 怎么兼容不同认证标签长度

如果一套已有 AES-GCM 协议使用的认证标签不是默认长度，Go 端应在创建 AEAD 时明确调用 cipher.NewGCMWithTagSize(block, tagSize)。可用的 tagSize 是 12 到 16 字节；加密端和解密端必须使用同一个值，不能在 Open 失败后临时换长度重试。

先把标签长度当成协议字段

认证标签不是可以随手删掉的尾部字节，而是 GCM 验证密文完整性的重要部分。默认的 cipher.NewGCM 使用标准标签长度；只有外部协议已经约定了其他长度时，才需要显式传入 tagSize。官方文档允许 12、13、14、15、16 字节五种取值，因此“兼容不同长度”的正确做法是读取协议配置后创建对应的 AEAD。

还要先确认密文布局：协议可能把 nonce 单独传输，也可能把 nonce 放在密文前缀；标签通常由 Seal 附加在密文尾部。Go 的 AEAD 不会替你猜测这些字段的位置，应用层必须先拆出正确的 nonce 和 ciphertext，再调用 Open。

用一个小项目固定 NewGCMWithTagSize 配置

下面的示例把标签长度作为协议参数，并在加密和解密路径复用同一个构造函数。示例只展示兼容配置与错误边界，真实项目仍应从安全配置中心或协议版本读取参数，不能把密钥硬编码进源码。

package main

import (
    "crypto/aes"
    "crypto/cipher"
    "crypto/rand"
    "fmt"
    "io"
)

// newAEAD 统一创建两端使用的 GCM，避免 tagSize 在不同调用点漂移。
func newAEAD(key []byte, tagSize int) (cipher.AEAD, error) {
    block, err := aes.NewCipher(key)
    if err != nil {
        return nil, fmt.Errorf("创建 AES block 失败: %w", err)
    }
    // 只有兼容既有协议时才指定非默认认证标签长度。
    return cipher.NewGCMWithTagSize(block, tagSize)
}

func main() {
    key := []byte("0123456789abcdef0123456789abcdef")
    aad := []byte("order:v1")
    plaintext := []byte("payment=ok")
    tagSize := 12 // 这里必须与协议和解密端保持一致。

    aead, err := newAEAD(key, tagSize)
    if err != nil {
        panic(err)
    }

    nonce := make([]byte, aead.NonceSize())
    if _, err := io.ReadFull(rand.Reader, nonce); err != nil {
        panic(fmt.Errorf("生成 nonce 失败: %w", err))
    }
    sealed := aead.Seal(nil, nonce, plaintext, aad)

    opened, err := aead.Open(nil, nonce, sealed, aad)
    if err != nil {
        panic(fmt.Errorf("认证失败，检查 tagSize、nonce 和 aad: %w", err))
    }
    fmt.Printf("明文=%s，标签开销=%d\\n", opened, aead.Overhead())
}

当 tagSize=12 时，Overhead() 应与标签开销对应；把同一段密文交给用 16 字节标签创建的 AEAD，通常会因为密文长度和认证边界不匹配而失败。这里故意让错误在构造阶段返回，便于服务启动或协议协商时尽早发现。

让 Seal 和 Open 使用同一套参数

跨服务兼容至少要锁定四项：密钥、tagSize、nonce 的长度与传输位置、附加认证数据。Open 不仅检查密文，还会认证 additionalData；例如加密端使用 order:v1，解密端改成 order:v2，即使明文没有变化也应当失败。

用 Overhead 和 Open 错误定位兼容问题

排查时先记录协议声明的标签长度，再比较 aead.Overhead() 与实际密文尾部长度。不要只看“密文能否解码”：Base64 解码成功不代表 GCM 认证成功。若 Open 返回认证错误，依次检查标签长度、nonce 字节和位置、附加数据的原始字节、密钥版本，最后才检查传输层是否截断。

如果协议可以升级，建议在消息头放入明确的协议版本或标签配置编号。新消息按新版本生成，旧消息按旧版本选择 AEAD；不要让接收端对同一密文盲试多个 tagSize，这会掩盖协议漂移，也容易把错误输入当成可兼容数据。

相关问题

新项目为什么不直接使用 NewGCMWithTagSize

如果没有外部兼容约束，优先使用 cipher.NewGCM，让标准 nonce 和标签配置减少误用面。带标签长度参数的构造函数更适合迁移已有协议。

tagSize 可以设置成 8 字节吗

不能按标准库这条 API 的约束设置为 8 字节；文档允许范围是 12 到 16 字节。若外部协议使用更短标签，需要重新评估协议实现和密码库边界，不能用截断后的 GCM 输出冒充兼容。

Open 失败时应该先换 tagSize 重试吗

不应该。先依据协议版本确定唯一配置，并检查 nonce、附加数据、密钥和密文布局；参数不确定时应拒绝消息并修复协商，而不是让解密端猜参数。