True Random Number Generator

电路可以测量细微的电波动，并将其转换成数字。关键在于测量结果中有多少是攻击者无法预测的。快速生成大量数据并不足够。因此，NIST SP 800-90B 会评估具体噪声源、采样方式、可能的处理步骤和运行检查。说出所用物理现象的名称，不能替代这些评估。 [1]

例如，一个源可能输出 0 的次数多于 1。称为 conditioning 的处理有助于降低这种偏差，将已有熵，也就是从攻击者角度看的不确定性，集中到更短的输出中。但它不能创造缺失的不确定性。因此，NIST SP 800-90B 将可认可的输出熵与输入及处理方法联系起来。即使是哈希这种计算得出的数据指纹，也不能证明原始值不可预测：知道输入，就能再次算出相同指纹。 [1]

如果噪声源不断返回同一个值，设备不能忽略这一情况。NIST SP 800-90B 用 Repetition Count Test 监测重复，用 Adaptive Proportion Test 监测异常频率。这些检查寻找特定故障，不会自动发现每一次攻击或所有缺陷。检测到持续故障后，源不能仍像正常运行时那样继续提供输出。 [1]

仅仅配备 TRNG 并不能证明钱包安全。还要看具体版本如何使用数据，以及遇到错误时如何处理。因此，NIST SP 800-90C 将熵源与后续生成器一起考虑。评估一个部件不等于评估整个钱包。即使随机源非常出色，也无法保护你后来主动泄露的备份。 [4]

长时间记录运行中的设备，与反复关闭、启动设备，观察到的是不同方面的行为。因此，NIST SP 800-90B 也包含重启测试。评估必须对应具体源及其运行条件。一个样本的结果不能自动推广到所有设备或环境。固件，也就是设备内部运行的程序，发生变化时，也可能需要重新评估。 [1]

技术文档中会出现 RDRAND 和 RDSEED 两条指令。Intel 在其硬件随机数生成器 DRNG 的指南中解释了它们。RDRAND 提供确定性生成器根据内部状态计算出的结果。RDSEED 则提供经过处理的熵，用于初始化，也就是建立生成器的起始状态。两条路径都可能始于物理源，但这并不意味着可以直接读取未经处理的噪声。 [2]

处理器不一定能为每次请求立即提供结果。因此，Intel 要求 RDRAND 和 RDSEED 都检查状态标志 CF：1 表示结果可用，0 表示不可用。只看目标寄存器里是否为数字零并不够；寄存器是处理器内部的小型存储位置。程序必须读取成功标志。处理器支持一条指令，不等于某次具体请求已经成功。 [2]

在 Linux 中，hw_random 接口可以通过 /dev/hwrng 读取硬件源，方式类似读取文件。但文档明确提醒，这个接口本身不对数据执行质量测试。因此，故障或被篡改的硬件可能返回错误数据，而应用仍能成功读取。读取成功不能证明熵足够。需要同时评估源本身，以及程序怎样使用它的结果。 [3]