Go cipher.StreamReader 怎样把流式解密接到 io.Reader

Go 的 crypto/cipher.StreamReader 适合解决一个很具体的问题：手里已经有一个按字节流工作的 cipher.Stream，还想把密文来源继续当作普通 io.Reader 来读。它会从底层 Reader 取数据，再在同一个缓冲区内调用 XORKeyStream，因此可以接到文件、网络连接、管道或 io.ReadAll。

官方地址：https://pkg.go.dev/crypto/cipher#StreamReader

最关键的一点是：StreamReader 只是“读取适配器”，不会替你选择算法、生成密钥或校验消息是否被篡改。下面围绕这个边界，给出一个可以直接套用的流式读取结构。

一、先分清 StreamReader 负责什么

它的结构可以理解为两个输入：S 是已经初始化好的流密码，R 是密文来源。每次调用 Read(dst) 时，底层 Reader 先把密文写进 dst，随后流密码把这段数据原地转换为明文。

因此它不会缓存全部内容，也不会自动重置流密码状态。流密码的状态会随着读取顺序持续推进，不能把同一个 StreamReader 随意倒回后重新读。

二、创建密文 Reader 和 cipher.Stream

下面用 AES-CTR 只演示 Reader 的拼接方式。示例中的密钥和 IV 是演示数据，真实系统应使用合适的密钥管理、随机 nonce/IV，并优先选择带认证的 AEAD 方案。

package main

import (
    "bytes"
    "crypto/aes"
    "crypto/cipher"
    "fmt"
    "io"
)

func newPlainReader(ciphertext []byte) (io.Reader, error) {
    // 演示用固定长度数据；生产环境不要把密钥和 IV 硬编码在源码中。
    key := []byte("0123456789abcdef")
    iv := []byte("abcdef0123456789")

    block, err := aes.NewCipher(key)
    if err != nil {
        // 保留构造错误，让调用方决定是否终止当前任务。
        return nil, fmt.Errorf("创建 AES 分组密码失败: %w", err)
    }

    // CTR 将分组密码包装成按字节推进的 cipher.Stream。
    stream := cipher.NewCTR(block, iv)

    // StreamReader 读取 ciphertext，并把每一段密文原地解密到 dst。
    return cipher.StreamReader{S: stream, R: bytes.NewReader(ciphertext)}, nil
}

func main() {
    reader, err := newPlainReader([]byte{0x1a, 0x2b, 0x3c})
    if err != nil {
        // 这里只展示错误出口；真实程序应记录上下文并停止使用无效 Reader。
        panic(err)
    }

    plaintext, err := io.ReadAll(reader)
    if err != nil {
        // ReadAll 会持续读取，直到 EOF 或底层 Reader 返回错误。
        panic(err)
    }
    fmt.Printf("明文字节数: %d\\n", len(plaintext))
}

这里的三字节输入只是为了让流程短小。真正的密文必须由同一算法、同一密钥以及匹配的初始状态产生；仅仅把任意字节交给 Reader，并不能得到有意义的明文。

三、接入分块读取，避免一次性加载全部内容

当密文来自大文件或长连接时，可以直接把 cipher.StreamReader 当普通 Reader 使用。每次调用只处理当前缓冲区中的字节，适合配合 io.Copy、bufio.Reader 或自定义分块循环。

func copyDecrypted(dst io.Writer, src io.Reader, stream cipher.Stream) error {
    // StreamReader 复用 copyBuf，明文不会要求一次性驻留内存。
    reader := cipher.StreamReader{S: stream, R: src}
    copyBuf := make([]byte, 32*1024)

    for {
        n, err := reader.Read(copyBuf)
        if n > 0 {
            // 只有 n 范围内的字节已经完成解密，不能写出整个缓冲区。
            if _, writeErr := dst.Write(copyBuf[:n]); writeErr != nil {
                return fmt.Errorf("写入明文失败: %w", writeErr)
            }
        }
        if err != nil {
            // n 和 err 可以同时出现，先消费 n，再判断是否结束。
            if err == io.EOF {
                return nil
            }
            return fmt.Errorf("读取密文失败: %w", err)
        }
    }
}

这段循环有两个容易遗漏的点：第一，写出范围必须是 copyBuf[:n]；第二，不能因为收到了错误就丢弃同一次读取已经返回的字节。

四、为什么要同时处理 n 和 err

io.Reader 允许一次读取返回 n > 0 以及一个错误。常见情况是最后一段数据已经读出，同时返回 io.EOF。StreamReader 会先对这 n 个字节做 XOR，再把底层错误原样带回。

五、资源关闭和安全边界

cipher.StreamReader 本身没有 Close 方法。若底层是文件、网络连接或其他需要释放的对象，仍然要关闭原始 Reader 对应的资源；Reader 适配器不会替你转发关闭动作。

另外，AES-CTR 这类流式模式只提供保密性，不提供消息认证。攻击者如果能修改密文，解密端可能得到被篡改的明文而没有认证错误。需要同时确认来源和完整性的业务，应使用合适的 cipher.AEAD，验证通过后再把明文交给后续逻辑；不要把 StreamReader 当作完整性校验器。

六、常见问题

StreamReader 能不能重复读取同一份密文？

不能把同一个流密码状态当成可回退对象。需要重新读取时，应重新创建底层 Reader，并按协议重新初始化匹配的 Stream。

为什么解密后长度和密文一样？

流式模式通常按原长度转换字节，长度不变是正常现象。长度变化或认证标签校验属于其他协议层职责。

能否直接对 AEAD 使用 StreamReader？

不能把 AEAD 当作 cipher.Stream 直接传入。AEAD 通常以 nonce、密文和附加数据为单位完成认证解密，应使用其对应的打开接口，而不是套用流式 Reader 适配。

总结

把流式解密接入 Go 的 io.Reader，核心就是创建匹配的 cipher.Stream，再用 cipher.StreamReader{S: stream, R: source} 组合。读取时始终先消费 n 个已经解密的字节，再处理 err；资源关闭由底层对象负责；需要完整性保护时，则应改用带认证的 AEAD 方案。