java - javax.crypto.KeyGenerator使用/random或/urandom生成 key 吗？

Question

考虑以下代码片段，其中我使用 AES-256 生成要加密的 key - 运行以下代码片段的线程被阻止。我怀疑这是否可能是由于未达到足够的熵的问题造成的。因此，线程可以挂起(或)看起来挂起，直到系统收集到足够的熵。

我在虚拟机上运行它，而不是在物理机上，并且我使用的是 Java8。

片段A

KeyGenerator keyGen = KeyGenerator.getInstance("AES");
keyGen.init(256);
SecretKey key = keyGen.generateKey();

以下article推断 SecureRandom 实例获取时为

SecureRandom secureRandom = new SecureRandom();

默认情况下用于生成熵的 NativePRNG 算法称为 SHA1PRNG，默认情况下使用 /dev/urandom，因此没有可能会发生线程阻塞。

我会谈谈为什么我要谈论这些东西。线路

keyGen.init(256);

在上面的代码片段中，在内部执行以下操作。

 public final void init(int paramInt) {
     init(paramInt, JceSecurity.RANDOM);
 }

这个JceSecurity.RANDOM有这个

static final SecureRandom RANDOM = new SecureRandom();

意味着它应该使用 /dev/urandom当未收集熵时，这不应该被阻止(或)挂起。

我正在分享我的java.security文件在这里。

有人可以深入了解为什么运行 SNIPPET A 的上述线程会阻塞吗？

Answer 1

最后，如果只是为了播种，随机数生成器将始终依赖于操作系统的熵源；毕竟从非随机环境中生成随机数是不可能的。

我可以想象，熵源数量有限的虚拟机很难填满条目池，即使只是一次。解决此问题的最佳方法是确保您的虚拟机安装了最新的客户端添加项。这些可以/应该使主机 RNG 可用于客户端计算机。

可以创建一个 SecureRandom 实例并将其作为参数传递给各种 init() 方法。然而，这并不能解决从一开始就阻塞的问题，而且它不必要地使代码变得复杂。最后，您永远不会知道哪个库或模块仍在实例化另一个 SecureRandom 实例。

因此，我会专注于修复客户端 VM 的 RNG，而不是 Java 代码。

<小时/>

请注意，NativePRNG 直接使用操作系统 RNG；它不使用“SHA1PRNG”。 SecureRandom() 使用包含该类实现的第一个提供程序；如果使用默认 PRNG，请确保您没有包含 PRNG 速度较慢的提供商。