Go语言加密解密错误处理与安全实践

本文深入剖析了Go语言中加密解密操作的常见陷阱与安全实践，强调密钥长度必须严格匹配AES要求（16/24/32字节）、密钥须由crypto/rand安全生成或经PBKDF2规范派生、base64解码后必须显式校验长度，同时警示NewGCM等构造函数绝不可忽略error返回值以防nil指针panic，指出RSA解密失败的模糊错误实为关键安全机制，需确保密钥对一致与密文完整，并严厉杜绝使用math/rand替代crypto/rand——因为哪怕一处随机性失守，整个加密体系都将形同虚设。

crypto/aes.NewCipher 报错“invalid key size”怎么办

Go 的 aes.NewCipher 要求密钥长度必须是 16、24 或 32 字节，对应 AES-128、AES-192、AES-256。传入其他长度（比如 12 字节或 base64 解码后没校验长度）就会 panic：crypto/aes: invalid key size。

常见错误场景：从配置读字符串当密钥、用 md5 哈希结果直接当 AES 密钥（md5 是 16 字节，看似能过，但不安全）、前端传来的 base64 密钥没做长度校验。

• 用 len(key) 显式检查，别依赖输入源的“看起来像密钥”
• 密钥生成建议走 crypto/rand.Read，而不是硬编码或哈希口令；若必须从口令派生，请用 golang.org/x/crypto/pbkdf2 + 指定轮数和 salt
• base64 解码后务必检查 len(decodedKey) == 32（以 AES-256 为例），否则提前 return error，别让 aes.NewCipher panic

crypto/cipher.NewGCM 返回 nil 且无错误提示

cipher.NewGCM 是个构造函数，它内部调用 aes.NewCipher，如果密钥非法，会直接 panic，不会返回 error。但很多人误以为它像 io.Read 那样返回 (n, error)，结果在 defer 中对 nil 的 gcm 对象调用 Seal，触发 panic：invalid memory address or nil pointer dereference。

典型误写：

gcm, _ := cipher.NewGCM(block) // 忽略 err，还用 _ 掩盖问题
defer gcm.Seal(nil, nonce, plaintext, nil) // gcm 是 nil，这里崩

• 永远检查 cipher.NewGCM 的第二个返回值（error），它只在 block 初始化失败时返回非 nil error
• 不要用 _ 忽略这个 error；Go 标准库设计上，这类构造函数失败就是不可恢复的编程错误
• GCM 模式下，nonce 长度必须是 12 字节（推荐）或按具体算法要求，传错长度会导致 Seal 或 Open 返回 cipher: message authentication failed

crypto/rsa.DecryptPKCS1v15 解密失败返回 “crypto/rsa: decryption error”

这个错误信息非常模糊，实际可能由多种原因导致：私钥不匹配、密文被篡改、填充损坏、或使用了错误的公钥加密却用私钥解密（看似合理，但 RSA 加解密方向不能反着来）。

关键点在于：RSA 解密失败几乎从不透露具体原因，这是故意的安全设计，防止攻击者通过错误类型侧信道推断密钥信息。

• 确保加密时用的是同一对密钥的公钥，且解密用对应私钥 —— 不要混淆 *rsa.PrivateKey 和 *rsa.PublicKey 类型
• 密文必须是完整、未截断的字节流；base64 解码后长度应等于私钥模长（如 2048 位私钥 → 密文应为 256 字节）
• 不要在生产环境用 DecryptPKCS1v15 处理用户输入；它易受 padding oracle 攻击，优先用 DecryptOAEP，并配合法定 hash（如 sha256）

crypto/rand.Reader 被误替换成 math/rand

用 math/rand 生成 IV、salt 或密钥，是 Go 加密代码里最隐蔽也最危险的错误之一。它输出可预测，密钥一旦可预测，整个加密就形同裸奔。

现象往往不报错，但安全审计工具（如 go-vet 或 gosec）会标红：Use of weak random number generator。

• IV、nonce、salt、密钥生成，一律用 crypto/rand.Reader，不是 rand.New(rand.NewSource(time.Now().UnixNano()))
• crypto/rand.Read(buf) 可能返回 io.ErrUnexpectedEOF，需检查；而 math/rand 的 Read 方法根本没实现，会 panic
• 测试中若需可重现的随机数，用 crypto/rand 的 mock（如提供一个固定字节切片的 io.Reader 实现），而非降级到 math/rand

真正难的不是调哪个函数，而是把“随机性来源”这个概念刻进每次声明变量的习惯里 —— 只要涉及密码学上下文，rand 前面没 crypto/ 就该警觉。

今天关于《Go语言加密解密错误处理与安全实践》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！