什么是java。安全egd选项是什么？

Question

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

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

我从未见过java。安全之前的egd选项。稍微搜索一下，它似乎用于在Java应用程序中配置随机数生成。

是这样吗？什么时候应用？

Answer 1

如果您使用的是JDK 8或更高版本，则不再需要此选项

Java已经解决了这个问题，下面是一些链接

大纲

修复了SHA1PRNG和NativePRNG，以正确尊重java.security文件中的SecureRandom种子源属性。（不再需要使用file：///dev/urandom和file：/dev/./urandom的模糊解决方案。）

有关更多信息（在页面中搜索random）：

https://docs.oracle.com/javase/8/docs/technotes/guides/security/enhancements-8.html

https://www.oracle.com/technetwork/java/javase/8-whats-new-2157071.html​​​​​​​

Answer 2

这与linux/dev/随机和/dev/urandom随机数生成器的区别有关。

摘自此链接

JavaBug 6202721指出，java.security.SecureRandom使用 /dev/random而不是 /dev/urandom即使 /dev/urandom是指定的，因为当时（大约2004年） /dev/urandom不能正常工作。这个错误从未被逆转过，因为 /dev/urandom工作得很好。因此，您必须通过使用 /dev/./urandom来模糊设置来伪造它，以强制使用SHA1PRNG而不是 /dev/random.

回答你的问题

什么时候应该申请？

基于上面的链接，这是Java版本5独有的东西，因为2004年Linux系统 /dev/urandom的问题。

Answer 3

TL； DR

如果在支持确定性随机位生成器（DRBG）的现代操作系统上运行Java8，我建议使用
-Djava。安全egd=file:/dev/uradom，以避免意外阻止代码。如果不确定正在使用的操作系统，我的建议是坚持原来的建议，即：
-Djava。安全egd=文件：/dev//铀矿

如果运行Java11，我建议只使用
-Djava。安全egd=文件：/dev//Uradom以确保：

1. 利用最强大的安全随机实施（DRBG），而不考虑基础平台
2. 避免意外阻止代码（securerandom.source=file:/dev/uradom）

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

Java应用程序可以而且应该使用Java。安全SecureRandom类使用加密强伪随机数生成器（CSPRNG）生成加密强随机值。java的标准JDK实现。util。随机类被认为不是强加密类。

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

默认情况下，JVM使用/dev/random为SecureRandom类种子，因此Java代码可能会意外阻塞。选项-Djava。安全egd=文件：/dev//用于启动Java进程的命令行调用中的uradom告诉JVM改用/dev/uradom。

额外的// 似乎使JVM使用SHA-1的SHA1PRNG算法作为PRNG（伪随机数发生器）的基础。它比指定/dev/uradom时使用的NativePRNG算法更强。

最后，有一个神话认为/dev/urandom是一个伪随机数生成器，一个PRNG，而/dev/random是一个“真实”的随机数生成器。这根本不是真的，/dev/random和/dev/uradom都是由同一个CSPRNG（加密安全伪随机数生成器）提供的。只有它们的行为不同：/dev/random根据某些估计，当其随机性池的熵用完时会阻塞，而/dev/urandom则不会。

那么低熵的系统呢？没那么糟。

事实证明，“看起来随机”是几个密码组件的基本要求，比如网络服务器的短暂会话密钥。如果你取一个密码散列的输出，它与随机字符串是无法区分的，所以密码将接受它。这就是使用SHA1PRNG算法的原因，因为它使用哈希函数和计数器以及种子。

什么时候应该申请？

我想说，总是这样。

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

编辑09/2020：
我已经改变了这个更新来反映测试：
-Java8在现代操作系统
-Java11，因为它是目前的长期支持（LTS）版本。


一条评论提到了Java8中SecureRandom类行为的变化。

修复了SHA1PRNG和NativePRNG，以正确尊重java.security文件中的SecureRandom种子源属性。（不再需要使用file：///dev/urandom和file：/dev/./urandom的模糊解决方案。）

这一点已在上文来源部分中引用的测试中指出。额外的//
我同意NativePRNG比SHA1PRNG更安全，但只有在现代操作系统上运行时才安全。因此，我相应地更新了我的结论，并将其移至顶部。

不过，我有一些消息想和大家分享。根据JEP-273，自Java 9以来，SecureRandom类实现了NIST 800-90Ar1中描述的三种确定性随机位生成器（DRBG）机制。这些机制实现了与SHA-512和AES-256一样强大的现代算法。

JDK以前有两种SecureRandom实现：

• 一个依赖于平台，基于本地调用或操作系统设备，例如在Unix上读取/dev/{u}随机或在Windows上使用CryptoAPI。最新版本的Linux和Windows已经支持DRBG，但旧版本和嵌入式系统可能不支持。
• 另一种是纯Java实现，它使用较旧的基于SHA1的RNG实现，不如经批准的DRBG机制使用的算法强。

与此同时，《Java11安全开发人员指南》仍在阅读

在Linux和macOS上，如果java.security中的熵收集设备设置为file：/dev/urandom或file：/dev/随机，则NativePRNG优先于SHA1PRNG。否则，优选SHA1PRNG。

为了阐明新的DRBG机制如何与以前的PRNG一起使用，我在macOS（Darwin）上使用了OpenJDK（build 11.0.7 10）进行了一些测试。结果如下：

-Djava。安全egd=file:/dev/random（这等于默认选项）
默认算法：NativePRNG
提供者：SecureRandom。NativePRNG算法来源：SUN


-Djava。安全egd=file:/dev/uradom
默认算法：NativePRNG
提供程序：SecureRandom。NativePRNG算法来源：SUN


-Djava。安全egd=文件：/dev//Uradom
默认算法：DRBG
提供程序：SecureRandom。DRBG算法来源：SUN


最后，即使在使用现代操作系统时，使用/dev/uradom作为随机性源仍然是最重要的，正如我们在这篇非常有趣的文章中所读到的：

共享/dev/random对于任何Linux容器技术来说都是一个挑战
虚拟化服务器上的低熵问题由于。。。在同一主机上运行的Linux容器竞争有限的熵。这类问题有时被称为踩踏群。/dev/random设备是一种稀缺的共享系统资源，Linux容器租户可能没有意识到他们正在共享。当他们都试图同时使用它时，他们实际上是在相互之间造成拒绝服务。

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