什么是java.security.egd选项? [英] What java.security.egd option is for?

问题描述

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

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)的现代OS上运行 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 类通过使用加密强度高的伪随机数生成器(

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使用

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.

低熵系统如何?还不错吧.

事实证明，看起来随机"是几个加密组件(如Web服务器的临时会话密钥)的基本要求.而且，如果采用加密哈希的输出，则它与随机字符串是无法区分的，因此密码将接受它.这就是使用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.

什么时候应该使用?

When is supposed to be applied?

我总是说.

来源:
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.

但是，我确实有一些我想分享的新闻.根据 JEP-273 ，自Java 9起， SecureRandom 类实现了确定性随机位生成器(DRBG)机制rel ="noreferrer"> NIST 800-90Ar1 .这些机制实现了强度高达SHA-512和AES-256的现代算法.

However, I do have some news that I'd like to share. As per the JEP-273, since Java 9 the SecureRandom class implements the three Deterministic Random Bit Generator (DRBG) mechanisms described in NIST 800-90Ar1. These mechanisms implement modern algorithms as strong as SHA-512 and AES-256.

JDK以前有两种 SecureRandom 实现:

The JDK previously had two kinds of SecureRandom implementations:

• 一个是平台相关的，并且基于本地调用或OS设备 例如在Unix上阅读/dev/{u}random或在 视窗.最新版本的Linux和Windows已经 支持DRBG，，但旧版本和嵌入式系统可能不支持.
• 另一种是使用较旧版本的纯Java实现 基于SHA1的RNG实现，其功能不如 经批准的DRBG机制使用的算法.

• One is platform-dependent and based on native calls or OS devices such as reading /dev/{u}random on Unix or using the CryptoAPI on Windows. The latest releases of Linux and Windows already support DRBG, but older releases and embedded systems might not.
• The other kind is a pure Java implementation that uses an older SHA1-based RNG implementation, which is not as strong as the algorithms used by approved DRBG mechanisms.

同时《 Java 11安全开发人员指南》 仍为

在Linux和macOS上，如果java.security中的熵收集设备 设置为file:/dev/urandom或file:/dev/random，则NativePRNG为 首选SHA1PRNG.否则，首选SHA1PRNG.

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

为了阐明新的DRBG机制如何与以前的PRNG一起使用，我在MacOS(Darwin)上使用AdoptOpenJDK(版本11.0.7 + 10)运行了一些测试.结果如下:

To clarify how the new DRBG mechanisms play together with the previous PRNGs, I ran some tests on macOS (Darwin) with AdoptOpenJDK (build 11.0.7+10). Here are the results:

-Djava.security.egd=file:/dev/random(这等于默认选项)
默认算法: NativePRNG
提供商: SecureRandom.NativePRNG算法，来自:SUN

-Djava.security.egd=file:/dev/random (This equals the default option)
Default algorithm: NativePRNG
Provider: SecureRandom.NativePRNG algorithm from: SUN

-Djava.security.egd=file:/dev/urandom
默认算法: NativePRNG
提供商: SecureRandom.NativePRNG算法，来自:SUN

-Djava.security.egd=file:/dev/urandom
Default algorithm: NativePRNG
Provider: SecureRandom.NativePRNG algorithm from: SUN

-Djava.security.egd=file:/dev/./urandom
默认算法: DRBG
提供商: SecureRandom.DRBG算法，来自:SUN

-Djava.security.egd=file:/dev/./urandom
Default algorithm: DRBG
Provider: SecureRandom.DRBG algorithm from: SUN

最后，即使在使用现代OS时，使用/dev/urandom作为随机性的源头仍然至关重要，因为我们可以在

Finally, the point of using /dev/urandom as source of randomness still remains paramount even when using modern OSes, as we can read on this very interesting post:

共享/dev/random对任何Linux容器技术都是一个挑战...
虚拟服务器上的信息量不足问题更加严重，因为...在同一主机上运行的Linux容器争夺有限的信息量.这种类型的问题有时被称为"牛群". /dev/random设备是一种稀缺的共享系统资源，Linux容器租户可能没有意识到他们正在共享.当他们都试图同时使用它时，它们实际上会导致彼此之间的拒绝服务.

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/博客/2017/08/12/random/

这篇关于什么是java.security.egd选项?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！