java.security.egd 选项的用途是什么?

In a project I'm working on, the application is launched using a command similar to this:

java -Djava.security.egd=file:/dev/urandom -jar app.jar

我以前从未见过 java.security.egd 选项.搜了一下，好像是用来在Java应用中配置随机数生成的.

I've never seen the java.security.egd option before. Searching a bit, it seems to be used to configure random number generation in a Java application.

对吗?什么时候申请?

推荐答案

TL;DR

如果在支持确定性随机位生成器 (DRBG) 的现代操作系统上运行 Java 8，我建议使用
-Djava.security.egd=file:/dev/urandom 以避免代码被意外阻塞.如果不确定正在使用的操作系统，我的建议是坚持原来的建议，即:
-Djava.security.egd=file:/dev/./urandom

如果运行 Java 11，我建议简单地使用
-Djava.security.egd=file:/dev/./urandom 来确保:

If running Java 8 on modern OSes with support to Deterministic Random Bit Generator (DRBG), I'd recommend using
-Djava.security.egd=file:/dev/urandom to avoid getting the code blocked unexpectedly. If not sure about the OS being used, my suggestion is to stick with the original recommendation, namely:
-Djava.security.egd=file:/dev/./urandom

If running Java 11, I'd recommend simply using
-Djava.security.egd=file:/dev/./urandom to make sure of:

1. 利用可用的最强大的 SecureRandom 实施 (DRBG)，无论基础平台如何
2. 避免代码被意外阻止 (securerandom.source=file:/dev/urandom)

1. leveraging the strongest SecureRandom implementation available (DRBG) regardless the underpinning platform
2. avoiding getting the code blocked unexpectedly (securerandom.source=file:/dev/urandom)

继续阅读以了解详细信息.

Read on to know the details.

Java 应用程序可以并且应该使用 java.security.SecureRandom 类通过使用加密强伪随机数生成器 (CSPRNG).java.util.Random 类的标准 JDK 实现不被认为具有加密强度.

Java applications can and should use java.security.SecureRandom class to produce cryptographically strong random values by using a cryptographically strong pseudo-random number generator (CSPRNG). The standard JDK implementations of java.util.Random class are not considered cryptographically strong.

类 Unix 操作系统具有 /dev/random，这是一个特殊文件，它提供伪随机数，访问从设备驱动程序和其他来源收集的环境噪声.但是，如果可用的熵比请求的少，它会阻塞；/dev/urandom 通常从不阻塞，即使伪随机数生成器种子在启动后没有完全用熵初始化.还有一个第三个特殊文件，/dev/arandom，它在启动后阻塞，直到种子被安全地初始化为足够的熵，然后再也不会阻塞.

Unix-like operating systems have /dev/random, a special file which serves pseudo random numbers accessing environmental noise collected from device drivers and other sources. However, it blocks if there is less entropy available than requested; /dev/urandom typically never blocks, even if the pseudorandom number generator seed was not fully initialized with entropy since boot. There still is a 3rd special file, /dev/arandom which blocks after boot until the seed has been securely initialized with enough entropy, and then never blocks again.

默认情况下，JVM 使用 /dev/random 为 SecureRandom 类播种，因此您的 Java 代码可能会意外阻塞.用于启动 Java 进程的命令行调用中的选项 -Djava.security.egd=file:/dev/./urandom 告诉 JVM 使用 /dev/urandom 代替.

By default, the JVM seeds the SecureRandom class using /dev/random, therefore your Java code can block unexpectedly. The option -Djava.security.egd=file:/dev/./urandom in the command line invocation used to start the Java process tells the JVM to use /dev/urandom instead.

额外的 /./ 似乎使 JVM 使用 SHA1PRNG 算法，它使用 SHA-1 作为 PRNG(伪随机数生成器)的基础.比指定/dev/urandom时使用的NativePRNG算法强.

The extra /./ seems to make the JVM to use the SHA1PRNG algorithm which uses SHA-1 as the foundation of the PRNG (Pseudo Random Number Generator). It is stronger than the NativePRNG algorithm used when /dev/urandom is specified.

最后，有一个神话，/dev/urandom 是一个伪随机数生成器，一个 PRNG，而 /dev/random 是一个真"随机数生成器.这根本不是真的，/dev/random 和 /dev/urandom 都由同一个 CSPRNG(加密安全伪随机数生成器)提供.只是它们的行为不同:根据某种估计，当随机池耗尽熵时，/dev/random 会阻塞，而 /dev/urandom 不会.

Finally, there is a myth that /dev/urandom is a pseudo random number generator, a PRNG, whilst /dev/random is a "true" random number generator. This is simply not true, both /dev/random and /dev/urandom are fed by the same CSPRNG (cryptographically secure pseudorandom number generator). Only their behaviour differs: /dev/random blocks when its randomness pool runs out of entropy according to some estimate, whilst /dev/urandom does not.

低熵系统呢?还不错.

事实证明，看起来随机"是几个加密组件的基本要求，例如网络服务器的临时会话密钥.如果您获取加密哈希的输出，它与随机字符串无法区分，因此密码将接受它.这就是使用 SHA1PRNG 算法的原因，因为它使用哈希函数和计数器，以及种子.

It turns out that "looking random" is the basic requirement for several cryptographic components such as webserver's ephemeral session keys. And if you take the output of a cryptographic hash, it is indistinguishable from a random string so that ciphers will accept it. That's the reason of using the SHA1PRNG algorithm, as it uses a hash function and a counter, together with a seed.

什么时候申请?

我会说总是.

来源:
https://gist.github.com/svrc/5a8accc57219b9548fe1
https://www.2uo.de/myths-about-urandom

编辑 09/2020:
我已更改此更新以反映测试:
-现代操作系统上的 Java 8
-Java 11，因为它是当前的长期支持 (LTS) 版本.

EDIT 09/2020:
I have changed this update to reflect the tests with:
-Java 8 on modern OSes
-Java 11 as it is the currently long-term support (LTS) version.

一条评论提到了 Java 8 中 SecureRandom 类的行为发生了变化.

A comment mentions a change on SecureRandom class' behaviour in Java 8.

已修复 SHA1PRNG 和 NativePRNG 以正确尊重 java.security 文件中的 SecureRandom 种子源属性.(不再需要使用 file:///dev/urandom 和 file:/dev/./urandom 的晦涩解决方法.)

SHA1PRNG and NativePRNG were fixed to properly respect the SecureRandom seed source properties in the java.security file. (The obscure workaround using file:///dev/urandom and file:/dev/./urandom is no longer required.)

上面来源"部分中引用的测试已经指出了这一点.需要额外的 /./ 将 Java 8 中 SecureRandom 使用的算法从 NativePRNG 更改为 SHA1PRNG.
我同意 NativePRNG 比 SHA1PRNG 更安全，但仅在现代操作系统上运行时.因此，我相应地更新了我的结论并将其移至顶部.

This had already been pointed out by the tests referenced on the Sources section above. The extra /./ is required to change the algorithm used by SecureRandom in Java 8 from NativePRNG to SHA1PRNG.
I agree that NativePRNG is more secure than SHA1PRNG, but only when running on modern OSes. I have therefore updated accordingly my conclusion and moved it to the top.