Go crypto/rand.Read 为什么不能按短读取处理

我在审查生成密钥材料的 Go 代码时，最容易看到的一类误判，是把所有 Read 都当成“可能只读一部分”。这个判断对普通 io.Reader 是必要的，但对 crypto/rand.Read 不成立：它的契约就是把目标切片完整填满，除非底层随机源发生不可恢复的错误。

官方地址：https://pkg.go.dev/crypto/rand

crypto/rand.Read 会调用 io.ReadFull 读取安全随机源，因此成功返回时 n 应该等于目标切片长度。不要把“短读取但没有错误”当作它的正常结果；如果输入源不是 crypto/rand.Read，再回到普通 Reader 的处理规则。

先把 crypto/rand.Read 的保证说清楚

crypto/rand.Read(b) 接收的是一个已经确定长度的字节切片。官方文档明确说明，它会填充安全随机字节、不会返回错误，并且总是完整填充 b。实现层面，它通过 io.ReadFull 读取包级共享的 rand.Reader，所以调用方不需要自己写“没读满就继续”的循环。

这里有一个容易混淆的层次：rand.Reader 本身是一个 io.Reader，而 crypto/rand.Read 是一个更强的便捷函数。前者遵守通用 Reader 接口，后者把“读满整个切片”作为自己的结果保证。

按目标长度申请随机字节

生成 32 字节密钥材料、16 字节 nonce 或固定长度随机令牌时，先把长度表达成切片，再直接调用 rand.Read。虽然当前标准库文档说明默认 Reader 下不会返回错误，保留错误分支仍能让封装函数的接口对未来替换或异常路径更清楚。

package main

import (
    "crypto/rand"
    "encoding/hex"
    "fmt"
)

func newKeyMaterial() ([]byte, error) {
    // 长度是密钥材料的协议约束，不要依赖读取次数来决定长度。
    key := make([]byte, 32)
    // rand.Read 成功返回时会填满 key，不需要手写短读取循环。
    if _, err := rand.Read(key); err != nil {
        return nil, fmt.Errorf("读取安全随机字节失败: %w", err)
    }
    return key, nil
}

func main() {
    key, err := newKeyMaterial()
    if err != nil {
        // 生成失败时不要继续使用未完成的密钥材料。
        panic(err)
    }
    // 十六进制只用于展示，实际协议应按自身格式传输或存储。
    fmt.Println(hex.EncodeToString(key))
}

示例中的 32 只是业务协议选定的长度，不代表 rand.Read 会自动选择安全长度。函数负责提供随机字节，密钥长度、编码方式、生命周期和存储策略仍由上层协议决定。

不要把短读取分支套在 rand.Read 外面

下面这种写法看似谨慎，实际上把普通 Reader 的不确定性错误地套到了 crypto/rand.Read 上：

func readToken() ([]byte, error) {
    token := make([]byte, 24)
    // 这里的 API 契约已经承诺完整填充，不应把 n 小于 len(token) 当正常结果。
    n, err := rand.Read(token)
    if err != nil {
        return nil, err
    }
    // 这个分支不是 rand.Read 的正常成功路径，截断会掩盖真正的异常。
    if n 

问题不在于检查长度本身会造成安全漏洞，而在于它改变了排查方向：如果这个分支真的被触发，优先怀疑调用的不是预期版本的 crypto/rand.Read、代码实际走了别的 Reader，或环境出现了需要立即中止的错误。更稳妥的做法是让封装函数围绕“目标长度 + 错误”表达意图，不把短读取写成可接受的业务状态。

需要自定义 Reader 时改用 io.ReadFull

测试注入 Reader、读取文件、网络协议或其他流式来源时，才需要认真处理短读取。普通 io.Reader 允许一次只返回一部分数据，即使暂时没有错误；调用方如果要求一个完整记录，就应该使用 io.ReadFull 把这个要求说出来。

package main

import (
    "fmt"
    "io"
)

func readFixedBlock(r io.Reader, size int) ([]byte, error) {
    // size 是调用方要求的完整记录长度，非正长度直接拒绝。
    if size 

这段代码把 fmt 一并列入 import，便于作为完整封装片段理解。它与 crypto/rand.Read 的关系是：前者让调用方对任意 Reader 显式表达“必须读满”，后者已经替调用方完成了这层选择。

按安全用途检查长度和来源

我会把“是否读满”和“是否适合安全用途”拆成两个问题。rand.Read 解决的是从密码学安全随机源取得指定长度字节；它不替你决定密钥长度，不替你做 Base64 或十六进制编码，也不替你管理密钥。若是令牌，还要考虑过期、绑定对象和重放策略；若是密钥，还要考虑算法要求与保存位置。

尤其不要因为测试里使用了一个会短读的 Reader，就反过来推断 crypto/rand.Read 的成功结果也会短读。测试替身应当验证你的封装函数是否正确处理它被设计来接收的接口；如果封装函数内部固定调用 rand.Read，那它测试的是随机字节生成契约，而不是任意 Reader 的行为。

最后用这几个问题判断是否写对

• 目标是不是固定长度的安全随机字节？是的话，优先用 crypto/rand.Read。
• 输入是不是一个可能短读的普通 io.Reader？是的话，需要完整块就用 io.ReadFull。
• 代码是否把随机字节编码后写进日志？如果是，先检查是否会泄露密钥或令牌。
• 是否把 n 当成 rand.Read 的正常成功结果？如果是，应删掉这层错误抽象。

相关问题

• rand.Reader.Read 和 rand.Read 有什么区别？前者是普通 Reader 接口调用，后者额外保证填满目标切片。
• rand.Read 为什么还返回 error？为了保留读取接口的错误表达，底层异常时仍应中止并处理。
• 读取文件时能直接用 crypto/rand.Read 吗？不能；文件是另一种输入源，需要按文件格式和 io.Reader 契约读取。