JEP 123: Configurable Secure Random-Number Generation | 可配置的安全随机数生成
摘要
增强安全随机数生成的 API，使其可以配置为在指定的质量和响应性约束条件内运行。
动机
目前，JDK 对 SecureRandom API 的默认实现可以使用阻塞/非阻塞系统调用和/或系统特性以及一些内部摘要来生成具有密码学安全性的随机数和种子值。尽力平衡速度和随机性质量，但这不适用于每个人。如果人们尝试调整实现配置，文档很混乱（或错误），最终无法提供所需的灵活性。熟悉安全随机数生成的人们已经要求有一个更好、更灵活的解决方案已经有一段时间了。
对于那些对实现不太熟悉的人来说，主要问题是不理解为什么在 SecureRandom 操作期间应用程序可能会出现挂起的情况，特别是在 Linux 系统上。当前的默认配置从 Unix 伪文件 /dev/random 获取种子材料，如果系统熵池中没有足够的数据可用，将会阻塞。虽然我们可能无法解决这个潜在问题，但我们应该努力减少此影响。
最终，这些问题可能导致应用程序阻塞或生成不足够熵的密钥，因此必须加以解决。多年来，已经通过一种未被充分记录的解决方法解决了几个升级问题，但易于配置性的根本问题仍然存在。
作为仍然存在困惑的一个例子，请参阅 bug 6202721 的评论部分。
描述
随机数据对许多加密构造和仿真系统至关重要。某些系统的随机数生成器（例如 /dev/random ）可以提供非常高质量的随机数据（用于长期存储的密钥等），但必须在获取到足够随机性之前阻塞。其他系统生成器（例如 /dev/urandom ）可以提供合理质量的随机性而不会阻塞，这适用于短期的会话密钥。还有其他可以测量系统特征以获取随机数据的伪随机数生成算法。JDK 的 SecureRandom 提供者使用了这些技术的组合，使实现配置变得不必要复杂和混乱，并且非常难以向开发人员和客户解释。
有一些应该调查和/或处理的错误：
- 6425477：更好地支持生成高熵随机数
- 6614946：
jre/lib/security/java.security配置文件中的错误 - 6577564：添加有关可能阻塞
SecureRandom.generateSeed()/nextBytes()的说明
根据我们决定如何解决这些问题的方式，它还可以解决：
- 6258213：请求包括一个
java.random库
目前还不清楚如何最好地解决这些问题。在 bug 6425477 中，提交者建议为 SecureRandom 添加一个名为 getTrueRandom 的新方法。这是一个选择，但不能解决配置问题。我们也可以使用像一个新的 SecureRandom 算法名称（"TrueRandom"，"NonBlockingRandom"）或添加新的 API 来支持算法特性或属性，例如：
sr = new SecureRandom( ..., SR_HIGHQUALITY|SR_NON_BLOCKING);随着工作进展，将会添加更多详细信息。
测试
我们应该确保默认实现与当前发布的产品类似。此外，应对每个配置进行测试，以确保文档中的配置选项按照广告宣传的方式起作用。对于正确性的测试可能很困难，因为无法确定所获得的数据是否确实来自所请求的源。
由于文件名的差异，为 Windows 创建了一个特殊的随机文件名。因此，这需要在所有可用平台上进行测试。
风险和假设
我们必须考虑向后兼容性。一些应用程序依赖于当前实现特定的默认值（非阻塞数据、阻塞种子），在进行更改时需要考虑这一点。
影响
- 其他 JDK 组件：任何需要
SecureRandom数据的组件（例如KeyGenerators、SSL/TLS 和 Kerberos 等协议） - 文档：新机制需要有文档记录。