【发布时间】:2018-01-06 16:33:38
【问题描述】:
考虑以下 sn-p,我使用 AES-256 生成要加密的密钥 - 运行以下 sn-p 的线程被阻塞。我怀疑这是否可能是由于没有达到足够的熵的问题。因此,线程可以挂起(或)看起来挂起,直到系统收集到足够的熵。
我在虚拟机上而不是在物理机上运行它,而且我使用的是 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);
上面的sn-p在内部做了如下动作。
public final void init(int paramInt) {
init(paramInt, JceSecurity.RANDOM);
}
这个JceSecurity.RANDOM拥有的是这个
static final SecureRandom RANDOM = new SecureRandom();
意味着它应该使用/dev/urandom,并且在未收集熵时不应该阻塞(或)挂起。
我在这里分享我的java.security 文件。
有人能解释一下为什么上面的线程运行SNIPPET A 块吗?
【问题讨论】:
-
第一个问题是:你能提供 MCVE 来重现这个阻塞问题吗?
-
不要装傻。。你是在问一个完整的sn-p,我可以从哪里重现这个问题@Andremoniy
-
我在询问 MCVE,如果它很大,可能会在 GitHub 上的某个地方共享,或者只是包含 main 方法和所有需要的逻辑的完整类。因为这听起来像是一个 JVM 错误,或者它可能只是代码中不可重现的错误配置或误用(例如,如果您在多个线程之间的共享内存中使用 keyGenerator)。
-
@Andremoniy : 这是完整的类文件docs.zoho.com/file/4xwcwd7e074921bb14c829d6d41dc58515106
-
这绝对不是 MCVE。
标签: java random cryptography virtual-machine entropy