Golang 实现文件流的加密读写接口-Golang-PHP中文网

不能用cipher.aead直接封装io.readwriter实现流式加解密，因gcm等aead模式要求每块加密使用唯一nonce并附带认证标签，而io.copy无法控制分块边界、无法注入nonce，且cipher.stream不提供完整性校验；必须分块处理，显式管理nonce生成与校验、错误传播及内存安全。

golang 实现文件流的加密读写接口

直接用 cipher.AEAD 封装 io.ReadWriter 是不可行的——GCM 等 AEAD 模式不支持流式加解密，强行套 io.Copy 会导致认证失败或 panic。必须分块处理，并显式管理 nonce、填充（如需）、错误传播。

为什么不能用 `cipher.Stream` 或 `io.Copy` 直接加密文件流

AEAD 模式（如 cipher.NewGCM）要求每次加密调用都携带完整 nonce 和附加数据（additionalData），且输出含认证标签（tag）。而 io.Copy 无法控制分块边界，更无法在每块插入唯一 nonce；cipher.Stream（如 CTR/OFB）虽支持流式，但不提供完整性校验，等于裸奔。

io.Copy(dst, cipher.StreamWriter{...}) 在小文件可能“看起来正常”，但大文件末尾常出现 io.ErrUnexpectedEOF 或解密后乱码，因为底层未对齐块边界
复用同一个 nonce 调用多次 Seal() 会直接破坏 GCM 安全性，不是报错而是静默失效
cipher.Stream 接口不校验认证，攻击者篡改密文任意字节，解密后仍返回“成功”的乱码，毫无察觉

`aead.Seal()` 分块加密时如何保证 nonce 唯一且可还原

每块加密必须使用独立 nonce，且解密端要能按顺序还原。不能靠计数器（易被跳过或重放），也不能用随机值后拼接——那样就失去块间顺序约束。最稳妥做法是：用主 nonce 衍生子 nonce，主 nonce 存文件头，子 nonce 由主 nonce + 块索引通过 hmac.Sum256 生成。

Go语言（Golang）1.26.0

Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。

下载

生成 12 字节主 nonce：rand.Read(nonce[:])，写入文件开头
每块 i（从 0 开始）计算子 nonce：hmac.New(sha256.New, nonce[:]).Write([]byte{byte(i)}); subNonce := hmac.Sum(nil)[:12]
这样既保证全局唯一（主 nonce 随机 + 块索引确定），又避免存储每块 nonce 的空间开销
解密时只需读一次主 nonce，再按块索引重复计算即可，无需额外元数据

读写过程中如何校验流完整性并提前中断错误

不能等全部写完才检查——若中间某块加密失败（如 I/O 错误、Seal 返回空切片），后续块继续写入只会污染密文。必须让每块加解密成为原子操作，并把 error 向上传播。

封装一个 func (w *encryptWriter) Write(p []byte) (n int, err error)，内部按 64KB 分块，每块调用 aead.Seal()，任一失败立即返回 err
解密端同理：func (r *decryptReader) Read(p []byte) (n int, err error) 中，先读够 aead.Overhead() 字节（含 tag），再调用 aead.Open()；若返回 cipher.ErrDecrypt，立刻终止，不尝试填充或忽略
特别注意：aead.Open() 失败时不会返回明文长度，不要用 len(out) > 0 判断成功——它可能返回 0 长度 + cipher.ErrDecrypt
若源 io.Reader 已关闭（如 *os.File 被提前 Close()），ReadFull 会返回 io.EOF 或 os.PathError("bad file descriptor")，必须在首块前捕获并拒绝加密