NIST SP 800-90A：DRBG 标准

密码学操作需要高质量的随机数：密钥生成、一次性随机数、初始化向量、盐值和会话令牌。真随机数生成器（TRNG）从物理来源（硬件噪声、中断、热噪声）中收集熵，但速度较慢且并不总是可用，尤其是在虚拟机或早期启动阶段。确定性随机比特生成器（DRBG）解决了这一问题：使用少量真熵为 DRBG 提供种子，再利用密码算法将其扩展为大量伪随机比特，使其在计算上与真随机比特不可区分。NIST SP 800-90A 定义了三种获批准的 DRBG 机制，几乎所有现代密码学实现都在使用它们。

DRBG 通过三个基本操作运行。实例化：使用 entropy_input（来自熵源）、一个随机数（用于确保唯一性的一次性值）以及可选的 personalization_string（特定于应用的上下文）初始化 DRBG 内部状态。生成：产生所请求数量的伪随机比特，并更新内部状态以防止回溯。重新播种：向 DRBG 状态注入新鲜熵，以提供预测抵抗性——重新播种后，即使攻击者知道先前的状态，也无法预测未来的输出。NIST 规定了最大的生成间隔（reseed_interval）：三种 DRBG 类型在强制重新播种前均可处理 2^48 次请求。

NIST SP 800-90A 定义了四个安全强度级别：112、128、192 和 256 比特。安全强度决定实例化时所需的最低熵以及生成输出的质量。对于 128 比特安全强度，熵输入必须至少提供 128 比特的熵。其关系是：security_strength 比特的熵 → 对于执行 2^security_strength 次操作的攻击者而言，DRBG 输出在计算上与随机值不可区分。密钥长度选择（AES-128 与 AES-256）以及哈希算法选择（SHA-256 与 SHA-512）都受到约束，必须匹配或超过所需的安全强度。参数配置过高（例如为 128 比特安全强度使用 SHA-512）是安全的，但会造成浪费；参数配置不足则会破坏安全性。

Hash_DRBG 维护两个状态值：V（用于生成输出的值）和 C（生成过程中加入的常量）。生成：hash_gen 通过迭代 H(0x01 || V)、H(0x01 || V+1)……来产生比特，直到获得足够的输出；随后使用 V = V + H(0x03 || V) + C + reseed_counter 更新 V。重新播种：使用 Hash_df（哈希派生函数）将当前 V 与新鲜熵组合起来，生成新的 V 和 C。Hash_DRBG 易于实现，安全性分析也较为简单，因此适用于资源受限的环境。NIST 建议使用 SHA-256 或 SHA-512 进行实例化。Hash_DRBG 用于 Java 的 SHA1PRNG（旧版本）以及 OpenSSL 的旧版 DRBG。

HMAC_DRBG 维护状态（密钥 K、值 V）。生成：反复计算 V = HMAC(K, V)，直到产生足够的输出；随后计算 K = HMAC(K, V || 0x00) 和 V = HMAC(K, V)。更新：接收 additional_input，并使用 HMAC 操作重新生成 K 和 V。HMAC_DRBG 具有基于 HMAC 安全性的简洁安全性证明（HMAC 的 PRF 假设）。它是最广泛推荐的 DRBG：OpenSSL（自 1.1.1 起）、mbedTLS、wolfSSL 和大多数 TLS 协议栈都使用 HMAC_DRBG。HMAC 构造在连续调用之间提供内置的混合，即使状态部分暴露，也会使回溯攻击更难实施。

CTR_DRBG 在计数器模式下使用分组密码（AES）。状态：密钥 K 和计数器 V。生成：加密连续的计数器值 E(K, V)、E(K, V+1)……并递增 V。更新：使用 Block_Cipher_df 根据 additional_input 派生新的 K 和 V。CTR_DRBG 是速度最快的 DRBG——AES-NI 硬件加速使其在现代处理器上比基于哈希的 DRBG 快几个数量级。它是 Windows CNG 中的默认 DRBG（CryptGenRandom 使用 AES-256 的 CTR_DRBG）、OpenSSL 3.0 中的默认 DRBG，也是 Linux 内核 RNG 使用的 DRBG（getrandom 系统调用）。CTR_DRBG 的安全性依赖于 AES 是伪随机置换这一性质，而数十年的分析已经充分支持了这一点。

预测抵抗性是一种性质：只要通过重新播种混入新鲜熵，即使攻击者先前入侵过 DRBG 状态，DRBG 输出仍然不可预测。设置 prediction_resistance_flag=true 的 DRBG 会在每次生成调用前访问熵源，以注入新鲜熵。没有预测抵抗性时，在时间 T 发生的状态泄露会使攻击者能够计算所有未来输出（前向安全性被破坏）。后向安全性（也称为抗回溯性）意味着即使当前状态已知，过去的输出仍然不可预测——HMAC_DRBG 和 CTR_DRBG 会在每次生成后通过更新步骤根据当前状态派生新密钥，从而实现这一点。

SP 800-90A 规定了 DRBG 算法，但没有规定熵源。SP 800-90B 定义了熵源的要求：必须对硬件噪声源进行特征分析和验证，熵估计必须保守，并且健康测试必须能够检测熵源故障。SP 800-90C 规定了如何将熵源与 DRBG 组合成完整的随机比特生成器。典型的熵源包括：CPU RDRAND/RDSEED（硬件 RNG，自 2012 年起 Intel/AMD CPU 便提供支持）、操作系统熵（Linux 上的 /dev/urandom、Windows 上的 BCryptGenRandom）、硬件安全模块、TPM 2.0 RNG 以及环境噪声（磁盘计时、网络抖动）。低熵条件（虚拟机、早期启动阶段）需要特殊处理，以避免生成弱种子。

FIPS 140-3（当前的密码模块验证标准）要求经过认证的模块在所有随机数生成操作中使用 NIST SP 800-90A DRBG。模块必须：使用获批准的 DRBG（Hash、HMAC 或 CTR）；从符合 SP 800-90B 要求的获批准熵源获取种子；执行通电自检（POST）以验证 DRBG 的运行；实施连续 RNG 测试（CRNGT）以检测熵源恒定为零或恒定为一的故障；并在熵源表明存在可用熵时支持重新播种。HSM（Thales Luna、AWS CloudHSM、Utimaco）、TLS 加速卡和网络加密设备通常要求使用经过 FIPS 140-3 验证的模块，从而推动了 SP 800-90A 的采用。

现代操作系统会维护内核级 DRBG，并使用硬件熵源为其播种。Linux 使用基于 ChaCha20 的 DRBG（从内核 5.17 开始，取代较早的 Fortuna 类设计），其熵来自 RDRAND、中断以及磁盘和网络事件。/dev/urandom 返回 DRBG 输出，并且在完成初始播种后不会阻塞。/dev/random 会一直阻塞，直到有足够的熵可用（这是旧行为，在近期内核中已基本移除）。getrandom(2) 系统调用是现代接口，仅在系统早期启动且 DRBG 尚未完成播种时阻塞。Windows 在内核 RNG 中使用 CTR_DRBG（AES-256），其熵来自 TPM 和硬件事件。应用程序应通过高级 API 使用操作系统提供的 DRBG，而不是根据时间戳或 PID 为自己的 DRBG 播种。

现实中的 DRBG 漏洞通常源于实现错误，而不是算法弱点。(1) 播种不足：只使用当前时间戳或 PID 播种，会产生攻击者可以猜测的种子。(2) 分叉盲区：进程发生分叉时，父进程和子进程共享相同的 DRBG 状态，因此会生成相同的随机数。修复方法：在分叉后重新播种（使用 pthread_atfork 或显式调用 getrandom）。(3) 虚拟机快照复用：恢复 VM 快照后，DRBG 状态会回到快照中的状态，从而生成之前已经出现过的输出。修复方法：在 VM 启动时注入唯一的熵（VIRTIO RNG）。(4) 静默忽略健康测试失败：检测到熵故障后仍继续生成输出的 DRBG，会提供攻击者可以预测的输出。(5) 在不同 DRBG 实例之间复用随机数。

使用新鲜熵为 DRBG 重新播种可以提供什么性质？

NIST SP 800-90A 定义了三种获批准的 DRBG 机制：Hash_DRBG（迭代散列，简单）、HMAC_DRBG（基于 HMAC，安全性证明简洁，部署广泛）以及 CTR_DRBG（AES 计数器模式，借助 AES-NI 速度最快，也是 Windows 和 OpenSSL 的默认机制）。三者都采用 Instantiate/Generate/Reseed 生命周期，并将 reseed_interval 限制为 2^48。安全强度（112–256 位）决定熵需求。预测抵抗性要求在每次 Generate 调用前重新播种。FIPS 140-3 要求使用带有 SP 800-90B 熵源的 SP 800-90A DRBG。分叉盲区、VM 快照复用和播种不足，是现实中最主要的实现陷阱。