跳到主要内容

JEP 123：可配置的安全随机数生成

概括​

增强用于安全随机数生成的 API，以便可以将其配置为在指定的质量和响应能力限制内运行。

动机​

目前，JDK 的 API 默认实现SecureRandom可以混合使用阻塞/非阻塞系统调用和/或系统特性以及一些内部摘要来生成加密安全的随机数和种子值。我们已尽最大努力尝试平衡速度与随机性质量，但这并不适合所有人。如果人们尝试调整实现配置，文档就会令人困惑（或错误），并最终无法提供所需的灵活性。一段时间以来，精通安全随机数生成的人们一直在寻求更好、更灵活的解决方案。

对于那些不太熟悉实现的人来说，主要的痛点是不理解为什么应用程序可能在SecureRandom操作过程中挂起，尤其是在 Linux 系统上。当前的默认配置从 Unix 伪文件中获取种子材料/dev/random，如果系统熵池中没有足够的数据，则会阻塞。虽然我们可能无法解决这个根本问题，但我们应该做出一些努力来帮助减少这种影响。

最终，这些问题可能导致应用程序被阻止或生成熵不足的秘密，因此必须得到解决。多年来，已经通过没有详细记录的解决方法解决了几次升级问题，但易于配置的根本问题仍然存在。

作为仍然存在的混乱的示例，请参阅bug 6202721的评论部分。

描述​

随机数据对于许多密码结构和模拟系统至关重要。一些系统随机数生成器（即/dev/random）可以保证非常高质量的随机数据（对于长期存储的密钥之类的东西），但必须阻塞，直到获得合适的随机性。其他系统生成器（即/dev/urandom）可以在不阻塞的情况下提供合理的质量随机性，这适用于寿命较短的会话密钥。还有其他 PRNG 算法可以测量系统特性以获得随机数据。 JDK 的SecureRandom提供者混合使用了这些技术，并且确实使实现配置变得不必要的复杂和混乱，并且很难向开发人员和客户解释。

有许多错误需要调查和/或解决：

  • 6425477：更好地支持高熵随机数的生成
  • jre/lib/security/java.security6614946：配置文件错误
  • 6577564：添加有关可能的块的注释SecureRandom.generateSeed()/nextBytes()

根据我们决定如何解决这些问题，它还可能解决：

  • 6258213：请求加入java.random图书馆

目前尚不清楚如何最好地解决这些问题。在错误 6425477 中，提交者建议了一种新方法来SecureRandom调用getTrueRandom.这是一个选项，但不能解决配置问题。我们还可以使用新的 SecureRandom 算法名称（“ TrueRandom”、“ NonBlockingRandom”），或添加新的 API 来支持算法特征或属性，例如，

sr = new SecureRandom( ..., SR_HIGHQUALITY|SR_NON_BLOCKING);

随着工作的进展，更多详细信息将添加到本文档中。

测试​

我们应该确保默认实现与当前发布的产品保持相似。此外，还应测试每个配置，以确保记录的配置选项按照广告的方式工作。正确性测试可能很困难，因为可能无法判断获得的数据是否真正来自所请求的来源。

由于文件名差异，为 Windows 创建了一个特殊的随机文件名。因此，这需要在所有可用平台上进行测试。

风险和假设​

我们必须考虑向后兼容性。某些应用程序依赖于当前特定于实现的默认设置（非阻塞数据、阻塞播种），并且在进行更改时需要考虑到这一点。

影响​

  • 其他 JDK 组件：任何需要SecureRandom数据的组件（例如KeyGeneratorsSSL/TLS 和 Kerberos 等协议）

  • 文件记录：新机制需要记录下来。