crypto/rand 的典型用法是这样的:

salt := make([]byte, saltLength)
n,err := rand.Read(salt)

它用一系列随机字节填充我在这里标记为“salt”的字节 slice 。

在什么情况下随机数生成器可能会失败？在 err 不为零的情况下退回到数学/兰德等价物是否不安全？

由于字节 slice 的长度是已知的，n 对我来说似乎也没用，我有什么理由不直接使用 _,err 代替它吗？

最佳答案

为了安全起见，您的代码应该看起来更像这样:

package main

import (
    "crypto/rand"
    "fmt"
)

func main() {
    saltLength := 16
    salt := make([]byte, saltLength)
    n, err := rand.Read(salt[:cap(salt)])
    if err != nil {
        // handle error
    }
    salt = salt[:n]
    if len(salt) != saltLength {
        // handle error
    }
    fmt.Println(len(salt), salt)
}

输出:

16 [191 235 81 37 175 238 93 202 230 158 41 199 202 85 67 209]

n 可能小于 len(salt)。您应该始终检查错误。

例如，获取随机数序列的众多方法之一是 Linux 上的 getrandom 系统调用或 Windows 上的 CryptGenRandom API 调用。

引用资料:

random: introduce getrandom(2) system call

CryptGenRandom function

附录:

crypto/rand 包是一个加密安全的伪随机数生成器。包 math/rand 不是加密安全的。

即使是一个简单的程序，路径也太多了，无法全部测试。因此，编写零缺陷和零错误程序的唯一方法是编写可读、可维护且可证明正确的代码。 Niklaus Wirth 的系统编程是一本很好的入门书。花时间构建一个健壮的通用形式是值得的，它可以很容易地适应每个特殊情况，并且随着需求的变化也很容易维护。

例如，对于 io.Reader 接口(interface)，典型的用法是循环模式。

func Reader(rdr io.Reader) error {
    bufLen := 256
    buf := make([]byte, bufLen)
    for {
        n, err := rdr.Read(buf[:cap(buf)])
        if n == 0 {
            if err == nil {
                continue
            }
            if err == io.EOF {
                break
            }
            return err
        }
        buf = buf[:n]
        // process read buffer
        if err != nil && err != io.EOF {
            return err
        }
    }
    return nil
}

type Reader

type Reader interface {
        Read(p []byte) (n int, err error)
}

Reader is the interface that wraps the basic Read method.

Read reads up to len(p) bytes into p. It returns the number of bytes read (0 <= n <= len(p)) and any error encountered. Even if Read returns n < len(p), it may use all of p as scratch space during the call. If some data is available but not len(p) bytes, Read conventionally returns what is available instead of waiting for more.

When Read encounters an error or end-of-file condition after successfully reading n > 0 bytes, it returns the number of bytes read. It may return the (non-nil) error from the same call or return the error (and n == 0) from a subsequent call. An instance of this general case is that a Reader returning a non-zero number of bytes at the end of the input stream may return either err == EOF or err == nil. The next Read should return 0, EOF regardless.

Callers should always process the n > 0 bytes returned before considering the error err. Doing so correctly handles I/O errors that happen after reading some bytes and also both of the allowed EOF behaviors.

Implementations of Read are discouraged from returning a zero byte count with a nil error, and callers should treat that situation as a no-op.

我们只想在开始Read 循环之前分配一次缓冲区。但是，我们希望编译器和运行时检测我们是否在 Read 循环中超出有效缓冲区长度 n，因此我们编写 buf = buf[:n ]。然而，当我们循环到下一个 Read 时，我们明确想要完整的缓冲区:buf[:cap(buf)。

写Read(buf[:cap(buf)])永远不会错。即使您现在可能没有 Read 循环，您以后可能会添加一个，并且您可能会忘记重置缓冲区长度。特定的 Read 实现可能有特殊情况，例如底层 ReadFull。现在你必须阅读和监控底层代码来证明你的代码是正确的。文档并不总是可靠的。而且您无法安全地切换到另一个 io.Reader Read 实现。

当您访问 salt slice 时，salt[:len(salt)]，您使用的是 len(salt) 而不是 n。如果它们不同，则说明存在错误。

"implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others." Jon Postel

关于random - crypto/rand read() 的两个返回值在什么情况下有用？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/26577917/