Golang实现文件流的加密解密_Golang安全传输文件-Golang-PHP中文网

不能用os.readfile/os.writefile或io.copy+blockmode实现透明加解密流，因其无法管理块对齐、iv/nonce生命周期、pkcs#7填充及gcm认证，易导致panic或解析失败。

golang实现文件流的加密解密_golang安全传输文件

os.ReadFile 和 os.WriteFile 不能用于透明加解密流 —— 它们读写的是完整字节切片，无法控制 IV/nonce 生命周期、块对齐或填充逻辑，解密后大概率报 "invalid PNG header" 或直接 panic。

常见错误是把 cipher.NewCBCEncrypter 或 cipher.Stream 实例直接塞进 io.Copy(dst, src)，结果小文件看似正常，大文件末尾乱码或解密失败。

io.Copy 不保证每次 Read 返回长度是 AES 块大小（16 字节）的整数倍，而 CryptBlocks 要求输入长度严格对齐，否则 panic："len(src) not multiple of block size"
CBC 模式状态依赖前一块输出，复用同一个 BlockMode 实例跨多次 Read 调用会污染内部状态
GCM 虽不要求对齐，但 Seal 必须传入完整明文块，且 nonce 绝对不可复用；io.Copy 无法保证分块边界与 nonce 构造逻辑同步
gzip、PNG、JSON 等格式对字节敏感，错一位就整个失效，不显式处理填充和 tag 位置，解密后必然解析失败

别幻想“一次 Seal 整个大文件”——内存扛不住，也违背流式设计初衷。GCM 允许分块，但每块需独立 nonce，且必须随密文一起传输。

Golang Spf13 Viper

Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。

下载

推荐 nonce 长度为 aesgcm.NonceSize()（固定 12 字节），用 crypto/rand.Read 生成，绝不可复用
更稳妥的做法：将块序号嵌入 nonce，例如 nonce := make([]byte, 12); binary.BigEndian.PutUint32(nonce[8:], uint32(chunkIndex))，前 8 字节随机填充
每块密文结构为：nonce(12B) + ciphertext + tag(16B)，写入时严格按此顺序
缓冲区大小设为 64 * 1024 或 128 * 1024，避开 16 的倍数陷阱（如 65535），避免因系统底层 read 边界导致最后一块长度异常
gcm.Seal 可安全处理任意长度明文，无需手动 PKCS#7 填充；但务必检查返回值是否为 cipher.ErrAuthFailed

很多人封装 io.Reader 解密器时，只做“读→解密→返回”，却忽略 GCM 的认证失败不会 panic，而是静默返回 nil 或错误数据。

首次 Read 前必须用 io.ReadFull(r, nonce) 提取前 12 字节作为 nonce，不足则直接 error
剩余数据必须完整读到内存（或至少缓存足够长度）才能喂给 gcm.Open；tag 固定在末尾 16 字节，不能靠猜测偏移
gcm.Open(dst, nonce, ciphertextWithTag, nil) 返回 nil 表示认证失败，此时应立刻终止流程，而不是继续往下 decode
如果密文来自 HTTP body 或 socket，必须确保连接未中断、数据未截断；io.ErrUnexpectedEOF 与 cipher.ErrAuthFailed 需区分处理
别用 bufio.Reader 包裹原始 reader 再解密——它内部 buffer 可能提前 consume 掉 nonce 或 tag，导致后续切片错位

密钥派生用的 salt、加密用的 nonce、密文本身，三者缺一不可，且顺序和长度必须硬编码进协议，不能靠文档“大家自觉遵守”。

推荐结构：salt(16B) + nonce(12B) + ciphertext+tag；salt 用于 scrypt.Key(pwd, salt, N, r, p, 32) 派生密钥
写入时用 os.OpenFile(dst, os.O_CREATE|os.O_WRONLY|os.O_TRUNC, 0600)，先 Write salt，再 Write nonce，最后循环写密文块
读取时严格按偏移切片：buf[0:16] 是 salt，buf[16:28] 是 nonce，buf[28:] 是密文流
永远不要用 os.Rename 覆盖原文件后再解密——万一解密失败，原始文件已丢；应始终写临时文件（如 dst + ".tmp"），成功后再 rename
如果文件来自 /dev/stdin 或 socket，file.Stat().Mode() & os.ModeDevice != 0 为 true，说明不支持 Seek，只能走纯流式路径，别尝试 rewind