更新

Question

请勿将其标记为重复。这是两个问题的后续问题。

我理解，替换

securerandom.source=file:/dev/urandom

与

securerandom.source=file:/dev/./urandom

$JAVA_PATH/jre/lib/security/java.security中的

将解决此问题。

我的问题是，在制作中这样做是否可以？这会对安全性产生什么影响（比如会话ID变得可预测）？如果这不太安全，还有其他方法可以更快地提供足够的熵吗？

更新

我使用openstack进行部署（或者只是说，使用AWS或GCP或任何其他云提供商）。因此，添加声卡等硬件设备对我来说不是一种选择。

Answer 1

在使用正确的搜索字词进行了一些广泛的Google搜索之后，我在DigitalOcean上看到了这篇很好的文章。我只是在这里引用相关部分。

Linux上有两个通用的随机设备：/ dev / random和的/ dev / urandom的。最好的随机性来自/ dev / random，因为它是a 阻止设备，并将等待足够的熵可用继续提供输出。假设你的熵足够了，你应该从/ dev / urandom看到相同的随机性质;然而，因为它是一个非阻塞设备，它将继续产生“随机” 数据，即使熵池耗尽。这可能导致更低质量随机数据，因为重复以前的数据的可能性更大。当可用熵低于a时，可能会发生很多不好的事情生产服务器，尤其是当此服务器执行加密时功能

因此，它存在潜在的安全风险。

填充熵池的解决方案

Linux已经从中获得了非常好的随机数据不同的硬件来源，但通常是无头机没有键盘或鼠标，产生的熵少得多。磁盘和网络I / O代表大多数熵生成源对于这些机器，这些机器产生非常稀疏的熵。由于很少有无头机器，如服务器或云服务器/虚拟机机器有任何类型的专用硬件RNG解决方案，存在若干用户域解决方案来生成额外的熵使用来自“比噪音更大”的设备的硬件中断磁盘，如视频卡，声卡等。这再一次证明了这一点不幸的是，服务器是一个问题，因为它们通常不包含任何一个

解决方案：已经

基于HAVEGE原理，以前基于其相关联库，hasged允许根据变化产生随机性处理器上的代码执行时间。因为它几乎是不可能的一段代码可以执行相同的准确时间，即使在相同硬件上的相同环境，运行单个的时间或多个程序应该适合播种随机源。该为实现种子系统的随机源（通常是 / dev / random）使用处理器时间戳计数器的差异（TSC）重复执行循环后

如何安装hasged

按照本文中的步骤操作。 https://www.digitalocean.com/community/tutorials/how-to-setup-additional-entropy-for-cloud-servers-using-haveged

Answer 2

如果有人遇到此问题

我只是通过删除所有调试器的BREAKPOINTS解决了我的问题。

Tomcat需要太多时间才能启动 - Java SecureRandom

更新

2 个答案:

填充熵池的解决方案

解决方案：已经

如何安装hasged