AES流加密不能直接用cipher.Stream加密任意长度明文，因其仅提供XOR字节流能力，不处理对齐、填充或认证，要求明文长度与密钥流严格匹配，否则导致错位或panic。
为什么 AES 流加密不能直接用 cipher.Stream 加密任意长度明文？
因为 cipher.Stream 接口只提供按字节流 XOR 的能力，不处理分组对齐、填充或认证——它默认假设你已手动确保明文长度与密钥流严格匹配。实际中，网络传输或文件读取的明文往往长度不可控，直接喂给 XORKeyStream 会导致末尾字节错位或 panic。
- 常见错误现象：
panic: crypto/cipher: input not full block（误当分组模式用）或解密后末尾乱码（明文长度 ≠ 密钥流生成长度） - 正确使用场景：实时音视频帧加密、日志行逐行加密封装、内存受限的嵌入式数据流处理
- 关键参数差异：
cipher.NewCTR和cipher.NewOFB都返回cipher.Stream，但 CTR 允许随机访问，OFB 更易受 IV 重用影响；两者都不自带完整性校验 - 性能提示：CTR 模式下可并行生成密钥流，OFB 必须串行；但 OFB 对密钥流错误更敏感（一个 bit 错，后续全错）
cipher.Stream 的 IV 必须每次都随机且唯一吗？
必须。IV 不是“随便填个数”，而是密钥流的起点偏移量。重复使用相同 IV + 密钥，等于生成同一段密钥流，攻击者 XOR 两段密文就能得到明文 XOR，直接破掉语义安全。
- 常见错误现象：测试时固定写死
[]byte{0,0,0,...}，上线后多个客户端用同一 IV，导致密文可被批量分析 - 实操建议：用
crypto/rand.Read生成足够长的随机 IV（CTR/OFB 均需 16 字节），和密文一起传输（如前缀拼接）；接收方先读 IV，再初始化 Stream - 注意兼容性：IV 长度必须与分组大小一致（AES 是 16 字节），传错长度会 panic：
panic: cipher: incorrect length IV - 别把 IV 当密码保管：它可公开，但绝不能复用；也不要用时间戳、计数器等可预测值替代真随机
如何安全地把 cipher.Stream 用在 HTTP 请求体加密中？
不能直接包装 http.Request.Body 后丢给 XORKeyStream——HTTP Body 是 io.ReadCloser，而 Stream 加密需要同步控制读写节奏，且必须保证整个流完整处理，否则残留未加密字节或密钥流错位。
- 典型踩坑：用
stream.XORKeyStream(dst, src)一次性读完 body，但 src 实际是 chunked 编码或 gzip 压缩后的流，导致解密端无法还原原始结构 - 推荐做法：在 handler 中先解压/解码（如有），再用
io.Pipe构建可控流；加密侧写入 pipe writer，解密侧从 pipe reader 读取 - 关键细节：CTR 模式下，IV 必须在请求头中传递（如
X-Enc-IV: base64...），且服务端要校验 IV 长度和是否为随机值；避免在 URL 或 cookie 里传 IV（可能被日志记录） - 性能提醒：不要在每次 HTTP 请求中新建 Block 加密器；复用
block := aes.NewCipher(key)实例，但每个请求必须新建 Stream（cipher.NewCTR(block, iv)）
为什么不用 golang.org/x/crypto/chacha20poly1305 替代 crypto/cipher 流加密？
因为 ChaCha20-Poly1305 是 AEAD（带认证加密），而 cipher.Stream 只做机密性。如果你没手动加 MAC 或签名，就等于裸奔——篡改密文、重放、截断都检测不到。
立即学习“go语言免费学习笔记（深入）”；
- 真实痛点：某 IoT 设备用 CTR 加密传感器数据，攻击者翻转密文第 3 字节，设备解密后温度值突变但无任何报错，直接触发误动作
- 迁移建议：只要业务允许，优先用
chacha20poly1305.NewX（X 表示带 nonce 的版本）；nonce 类似 IV，也必须唯一，但允许非随机（如单调递增计数器 + 固定 salt） - 兼容性代价：ChaCha20-Poly1305 输出比输入长 16 字节（Auth tag），老协议若硬编码长度会失败；而纯 Stream 加密输出等长
- 别忽略边界：AEAD 的 nonce 长度是 12 字节（不是 16），传错会 panic：
invalid key or nonce length
