Golang实现对加密配置文件的解密流程-Golang-PHP中文网

解密前必须验证密钥和文件完整性：密钥需为16/24/32字节，密文须含合法iv前缀（如前16字节）且总长为16字节整数倍；推荐用hmac-sha256签名并校验，失败则直接报错，不进入解密流程。

golang实现对加密配置文件的解密流程

解密前必须验证密钥和文件完整性

密钥错误或配置文件被篡改时，aes.Decrypt 通常不会报错，而是输出乱码或 panic（比如 crypto/aes: invalid key size 或 crypto/cipher: incorrect length iv）。实际项目中，必须在解密前校验：密钥是否为 16/24/32 字节；密文是否带合法的 IV 前缀（如前 16 字节）；整个密文长度是否为块大小（16 字节）的整数倍。

推荐做法是：加密时用 HMAC-SHA256 对密文签名，将签名附在密文末尾；解密前先分离出签名，用相同密钥重新计算并比对。不这么做，攻击者可随意修改密文导致解密后静默失败或服务异常。

os.ReadFile 读取配置文件后，先检查长度 ≥ 32（假设 16 字节 IV + 16 字节 HMAC）
用 hmac.New 和原始密钥计算预期签名，与末尾 32 字节比对
签名不匹配直接返回 fmt.Errorf("config integrity check failed")，不进入解密逻辑

使用 AES-CBC 模式时 IV 必须从密文头部提取

硬编码 IV 或复用同一 IV 会导致相同明文生成相同密文，严重削弱安全性。Golang 的 cipher.BlockMode 不自动管理 IV，必须手动处理。

典型错误是把 IV 当作固定值传入 cipher.NewCBCDecrypter，而实际应从密文开头截取：

Golang Naming

Go（Golang）命名规范 — 包括包、构造函数、结构体、接口、常量、枚举、错误、布尔值、接收器、getter/setter、函数等。

下载

// 正确：从密文前 16 字节取 IV
iv := ciphertext[:aes.BlockSize]
ciphertext = ciphertext[aes.BlockSize:]
block, _ := aes.NewCipher(key)
mode := cipher.NewCBCDecrypter(block, iv)
mode.CryptBlocks(plaintext, ciphertext)

IV 长度必须等于 aes.BlockSize（16 字节），否则 NewCBCDecrypter panic
密文长度必须是 16 的倍数，否则 CryptBlocks 不会报错但结果错误
不要用 rand.Read 在解密时生成新 IV——IV 是加密时生成并拼接进密文的

JSON 解密后需用 json.Unmarshal 处理字节流，而非 string 转换

解密得到的是 []byte，直接转 string 再传给 json.Unmarshal 容易因 BOM、非法 UTF-8 字节导致 invalid character 错误。尤其当原始配置含非 ASCII 字符（如中文、emoji）时更明显。

跳过 string(plaintext) 这步，直接传 plaintext 给 json.Unmarshal
若解密后首字节是 0xEF 0xBB 0xBF（UTF-8 BOM），应提前切掉：bytes.TrimPrefix(plaintext, []byte{0xEF, 0xBB, 0xBF})
确认原始加密前 JSON 已通过 json.Marshal 序列化——不能直接加密 map 或 struct，必须是字节流