go 标准库的 aes-gcm 和 aes-cbc 加密接口不支持流式处理，导致大文件必须全部载入内存；本文详解其设计限制根源，并提供安全、可落地的分块流式加密方案。
go 标准库的 aes-gcm 和 aes-cbc 加密接口不支持流式处理，导致大文件必须全部载入内存；本文详解其设计限制根源，并提供安全、可落地的分块流式加密方案。
Go 的 crypto/cipher 包中，cipher.BlockMode（如 CBC）和 cipher.AEAD（如 GCM）接口的设计初衷并非面向任意长度流式加解密，而是面向“完整消息”（whole-message）处理。这直接导致开发者无法将 io.Reader/io.Writer 与 StreamWriter/StreamReader 无缝集成——看似是 API 局限，实则根植于密码学模式本身的语义约束与安全要求。
CBC：可流式，但需手动处理填充与边界
CBC 是分组密码链式模式，天然支持逐块加解密（只要维持正确的 IV 链接）。Go 提供了 cipher.BlockMode 接口，例如通过 cipher.NewCBCEncrypter 获取实例后，可循环调用 CryptBlocks(dst, src []byte) 实现块级流式处理：
func encryptCBCStream(reader io.Reader, writer io.Writer, block cipher.Block, iv []byte) error {
stream := cipher.NewCBCEncrypter(block, iv)
buf := make([]byte, block.BlockSize()) // 读缓冲区（按块对齐）
pad := pkcs7Padding(buf[:0], block.BlockSize()) // 需自行实现 PKCS#7 填充
for {
n, err := reader.Read(buf)
if n > 0 {
// 填充最后一块（仅当非整块时）
if n < len(buf) && err == io.EOF {
padded := append(pad[:0], buf[:n]...)
stream.CryptBlocks(padded, padded)
_, writeErr := writer.Write(padded)
return writeErr
}
stream.CryptBlocks(buf[:n], buf[:n])
_, writeErr := writer.Write(buf[:n])
if writeErr != nil {
return writeErr
}
}
if err == io.EOF {
break
}
if err != nil {
return err
}
}
return nil
}⚠️ 注意事项：
- Go 标准库不提供内置填充实现，必须自行实现 PKCS#7（或 ZeroPadding，但需谨慎验证接收端兼容性）；
- IV 必须唯一且不可预测（推荐使用 crypto/rand 生成），且需随密文一同传输（如前置 16 字节）；
- 解密端需严格校验填充有效性，防止 Padding Oracle 攻击。
GCM：流式可行，但认证机制强制分块
GCM 本质是流式模式（CTR + GHASH），但 Go 的 cipher.AEAD 接口将加密、认证标签生成与验证耦合为原子操作：Seal() 输出 ciphertext || tag，Open() 要求整个输入包含 tag 并一次性验证。这意味着无法对无限流做端到端认证——因为 tag 只能在全部数据处理完毕后生成。
安全的流式方案是：将数据分割为固定大小（如 64KB）的 chunk，每个 chunk 独立执行 GCM 加密，并附带独立 tag：
const chunkSize = 64 * 1024
func encryptGCMStream(reader io.Reader, writer io.Writer, aead cipher.AEAD, nonceFn func() []byte) error {
buf := make([]byte, chunkSize+16) // +16 字节预留 tag 空间
for {
n, err := io.ReadFull(reader, buf[:chunkSize])
if n == 0 && err == io.EOF {
break // 流结束
}
if err != nil && err != io.ErrUnexpectedEOF {
return err
}
nonce := nonceFn() // 每次生成唯一 nonce（如 12 字节随机数）
ciphertext := aead.Seal(buf[:0], nonce, buf[:n], nil)
if _, writeErr := writer.Write(ciphertext); writeErr != nil {
return writeErr
}
if err == io.EOF || err == io.ErrUnexpectedEOF {
break
}
}
return nil
}✅ 关键安全实践：
- Nonce 绝对不可重用：每个 chunk 必须使用全新、密码学安全的 nonce（GCM 推荐 12 字节随机 nonce）；
- Chunk 大小权衡：过小增加 nonce/tag 开销，过大削弱实时性与错误隔离能力；
- 解密端必须逐 chunk 验证 tag：任何 chunk 的 tag 验证失败即应中止，防止篡改扩散。
替代建议与总结
若项目对流式 GCM 有强需求且无法接受分块复杂度，可考虑：
- 使用 mbedtls（C 实现，Go 可通过 cgo 调用），其 API 显式暴露 gcm_starts/gcm_update/gcm_finish，天然支持增量认证；
- 或评估 ChaCha20-Poly1305（Go 原生支持 cipher.Chacha20Poly1305），其 AEAD 接口行为与 GCM 一致，但无分组大小限制，更适合高吞吐流场景。
归根结底，Go 标准库的“不可流式”并非技术不可行，而是安全优先的设计取舍：GCM 的 tag 语义要求完整性验证与数据边界强绑定，而 CBC 的填充缺失则反映了标准库聚焦通用基元而非应用层协议。掌握分块策略与 nonce/IV 管理，即可在 Go 中构建既高效又符合密码学最佳实践的大文件流式加密管道。
