Go 语言 AES 加密中避免明文填充为“A”的正确实践-Golang-PHP中文网

Go 语言 AES 加密中避免明文填充为“A”的正确实践

本文详解 go 中 aes 加密时因 iv 处理不当导致密文头部出现连续 'a' 字符的问题，指出根本原因是未正确写入 iv 到密文起始位置，并提供基于标准库的 cfb 安全实现及更推荐的 aead（gcm）替代方案。

本文详解 go 中 aes 加密时因 iv 处理不当导致密文头部出现连续 'a' 字符的问题，指出根本原因是未正确写入 iv 到密文起始位置，并提供基于标准库的 cfb 安全实现及更推荐的 aead（gcm）替代方案。

在 Go 的 AES 加密实践中，一个常见却隐蔽的错误是：加密后 Base64 编码的密文以大量 A 字符开头（如 AAAAAAAAACbglBtdgH3ajX1jgkOaVAsFYyDxRRI=）。这并非加密算法本身出错，而是IV（初始化向量）未被正确写入密文缓冲区所致。

回顾问题代码：

ciphertext := make([]byte, aes.BlockSize+len(plaintext))
iv := commonIV
stream := cipher.NewCFBEncrypter(block, iv)
stream.XORKeyStream(ciphertext[aes.BlockSize:], plaintext) // ❌ 仅填充了明文部分
// 缺失关键步骤：未将 IV 写入 ciphertext[:aes.BlockSize]

由于 ciphertext 是用 make([]byte, ...) 创建的切片，其初始内容为全零字节（即 \x00）。当使用 base64.URLEncoding 编码时，\x00 对应 Base64 字符表中的 'A'（Base64 编码将每 3 字节映射为 4 个字符，\x00\x00\x00 → "AAAA"）。因此，未显式写入 IV 的前 aes.BlockSize 字节，在编码后就表现为一长串 A。

✅ 正确做法是：将随机生成的 IV 显式复制到密文头部，并确保每次加密使用全新 IV：

func Encrypt(key []byte, text string) string {
    block, _ := aes.NewCipher(key)
    plaintext := []byte(text)

    // ✅ 每次生成唯一、随机的 IV（不可复用！）
    iv := make([]byte, aes.BlockSize)
    if _, err := rand.Read(iv); err != nil {
        panic(err)
    }

    ciphertext := make([]byte, aes.BlockSize+len(plaintext))
    // ✅ 将 IV 写入密文前缀
    copy(ciphertext[:aes.BlockSize], iv)

    stream := cipher.NewCFBEncrypter(block, iv)
    stream.XORKeyStream(ciphertext[aes.BlockSize:], plaintext)

    return base64.URLEncoding.EncodeToString(ciphertext)
}

func Decrypt(key []byte, enc string) string {
    ciphertext, _ := base64.URLEncoding.DecodeString(enc)
    block, _ := aes.NewCipher(key)

    if len(ciphertext) <p>⚠️ 重要注意事项：</p>

绝不可复用 IV：commonIV 是严重安全隐患，会导致相同明文产生相同密文，破坏语义安全性；
CFB 模式不提供完整性校验：攻击者可篡改密文而解密端无法察觉，生产环境强烈建议改用 AES-GCM（AEAD 模式），它同时保证机密性与完整性；
优先使用经审计的封装库：如 github.com/gtank/cryptopasta，其 Encrypt()/Decrypt() 函数已内置安全 IV 生成、GCM 封装与错误处理，避免手写密码学逻辑的风险。