熵源、CSPRNG状态与重播种

一个好的确定性生成器像一部由秘密种子启动的机器：正常情况下输出难预测，但复制同一机器状态和输入就会复制未来输出。算法质量不会阻止备份把秘密状态也一并克隆。

重播种的价值来自引入新的、攻击者不知道的熵。把时间戳、进程号或生成器自己的输出再哈希一遍，不会自动带来这种资源。它们可以帮助实例区分，但不能替代秘密熵下界。

假设两个进程在fork后得到相同S，随后都请求32字节且additional相同。由Generate确定性，两个R与下一状态严格相同。如果它们各把R用作临时DH秘密，可能重复临时公钥；如果把R用作nonce，也可能在共享记录密钥下产生冲突。修复应按平台随机服务的fork处理或独立重初始化契约执行，不自行假设“PID不同所以安全”。

再设攻击者在时刻t读到完整S。若以后所有输入公开，攻击者运行相同Generate就能预测后续输出。即使每轮用单向函数更新状态，这个向前模拟仍成立。只有之后成功混入足够新的秘密熵，并由正确的重播种构造处理，才有希望恢复未来输出的不可预测性。

回溯抵抗关注当前状态泄漏是否能恢复过去已释放的输出；它通常需要单向更新并擦除旧状态。预测抵抗关注当前泄漏后未来输出何时重新安全，依赖新熵。两个目标的时间方向不同，也都不等于“输出通过随机性统计测试”。

有限采样可以发现明显卡死，例如源持续输出同一个值；不能仅因直方图均匀就证明攻击者不知道生成规律。熵源评估应结合物理/系统模型、旁信息和保守估计；健康测试以该模型为前提侦测运行故障，不是每次调用重新证明源有足够熵。

应用应使用平台提供且满足任务要求的密码随机接口，并检查失败；库内部如何从系统熵初始化、重播种和处理fork属于该接口的实现责任。应用自己维护长期种子文件时，则必须承担权限、并发、回滚与安全删除等额外义务。

本单元为了可复算而使用公开固定种子，故没有从真实熵源生成任何用户密钥，也没有测试操作系统CSPRNG。其输出可以验证算法字节一致性，不能被重新包装为安全随机材料。评审随机服务时，应问清输出安全模型与状态生命周期，而不是只看算法名。