java - java.security.egd 选项是干什么用的？

Question

在我正在处理的一个项目中，应用程序是使用类似于以下的命令启动的:

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

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

这样对吗？应该什么时候应用？

Answer 1

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

借力最强 SecureRandom 无论基础平台如何，都可以实现(DRBG)

避免代码意外阻塞 ( securerandom.source=file:/dev/urandom )

请继续阅读以了解详细信息。

Java 应用程序可以而且应该使用 java.security.SecureRandom 类通过使用密码强的伪随机数生成器 ( CSPRNG ) 生成密码强的随机值。 java.util.Random 类的标准 JDK 实现不被认为是加密强的。
类 Unix 操作系统有 /dev/random ，一个特殊文件，它提供伪随机数访问从设备驱动程序和其他来源收集的环境噪声。但是，如果可用的熵少于请求的熵，它就会阻塞； /dev/urandom通常从不阻塞，即使伪随机数生成器种子自启动以来没有完全用熵初始化。还有第三个特殊文件， /dev/arandom它在启动后阻塞，直到种子用足够的熵安全地初始化，然后不再阻塞。
默认情况下，JVM 种子 SecureRandom 类使用 /dev/random ，因此您的 Java 代码可能会意外阻塞。选项 -Djava.security.egd=file:/dev/./urandom在用于启动 Java 进程的命令行调用中告诉 JVM 使用 /dev/urandom反而。
额外的 /./似乎让JVM使用 SHA1PRNG algorithm它使用 SHA-1 作为 PRNG(伪随机数生成器)的基础。它比 /dev/urandom 时使用的 NativePRNG 算法更强被指定。
最后，还有一个神话是 /dev/urandom是一个伪随机数生成器，一个 PRNG，而 /dev/random是一个“真正的”随机数生成器。这根本不是真的，两者都是 /dev/random和 /dev/urandom由相同的 CSPRNG(密码安全伪随机数生成器)提供。只有他们的行为不同: /dev/random根据一些估计，当它的随机池用完熵时阻塞，而 /dev/urandom才不是。
低熵系统呢？没那么糟糕。
事实证明，“看起来随机”是一些加密组件(例如网络服务器的临时 session key )的基本要求。如果您采用加密散列的输出，它与随机字符串无法区分，因此密码将接受它。这就是使用 SHA1PRNG 算法的原因，因为它使用散列函数和计数器以及种子。

When is supposed to be applied?

总是，我会说。
来源:
https://gist.github.com/svrc/5a8accc57219b9548fe1
https://www.2uo.de/myths-about-urandom

编辑 09/2020:
我已更改此更新以反射(reflect)以下测试:
-现代操作系统上的Java 8
-Java 11，因为它是当前的长期支持 (LTS) 版本。
评论提到 上的更改SecureRandom Java 8 中类的行为。

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.)

上面“来源”部分中引用的测试已经指出了这一点。额外的 /./需要更改 使用的算法SecureRandom 在 Java 8 中从 NativePRNG 到 SHA1PRNG。
我同意 NativePRNG 比 SHA1PRNG 更安全， 但仅限在现代操作系统上运行时 .因此，我相应地更新了我的结论并将其移至顶部。
但是，我确实有一些消息要分享。根据 JEP-273 , 自 Java 9 起 SecureRandom 类实现了 NIST 800-90Ar1 中描述的三个确定性随机位生成器 (DRBG) 机制.这些机制实现了与 SHA-512 和 AES-256 一样强大的现代算法。
JDK以前有两种 SecureRandom 实现:

一种是平台相关的，基于 native 调用或操作系统设备
如阅读/dev/{u}random在 Unix 上或使用 CryptoAPI
视窗。最新版本的 Linux 和 Windows 已经
支持 DRBG，但旧版本和嵌入式系统可能不支持。

另一种是纯 Java 实现，它使用较旧的
基于SHA1的RNG实现，不如
被批准的 DRBG 机制使用的算法。

同时 Java 11 Security Developer’s Guide还在读

On Linux and macOS, if the entropy gathering device in java.securityis set to file:/dev/urandom or file:/dev/random, then NativePRNG ispreferred to SHA1PRNG. Otherwise, SHA1PRNG is preferred.

为了阐明新的 DRBG 机制如何与以前的 PRNG 一起使用，我在 macOS(达尔文)上使用 AdoptOpenJDK(构建 11.0.7+10)进行了一些测试。结果如下:
-Djava.security.egd=file:/dev/random (这等于默认选项)
默认算法: native PRNG
提供者:SecureRandom.NativePRNG 算法来自:SUN -Djava.security.egd=file:/dev/urandom默认算法: native PRNG
提供者:SecureRandom.NativePRNG 算法来自:SUN -Djava.security.egd=file:/dev/./urandom默认算法: DRBG
提供者:SecureRandom.DRBG 算法来自:SUN

最后，使用 /dev/urandom的要点即使在使用现代操作系统时，随机性来源仍然是最重要的，正如我们可以在 this very interesting post 上阅读的那样:

Sharing /dev/random is a challenge for any Linux container technology...
The low amount of entropy on virtualized servers problem is exacerbated because ... Linux Containers running on the same host compete for a limited supply of entropy. This type of problem is sometimes referred to as a stampeding herd. The /dev/random device is a scarce shared system resource that Linux Container tenants likely have not realised they are sharing. When they all try to use it at the same time they are effectively causing a denial of service on each other.

来源:
https://www.openssl.org/blog/blog/2017/08/12/random/