1. Overview
When launching the Java Virtual Machine (JVM), there are various properties we can define that will alter how our JVM behaves. One such property is java.security.egd.
In this tutorial, we’ll examine what it is, how to use it, and what effect it has.
2. What Is java.security.egd?
As a JVM property, we can use java.security.egd to affect how the SecureRandom class initializes.
Like all JVM properties, we declare it using the -D parameter in our command line when launching the JVM:
java -Djava.security.egd=file:/dev/urandom -cp . com.baeldung.java.security.JavaSecurityEgdTester
Typically, if we’re running Java 8 or later and are running on Linux, then our JVM will use file:/dev/urandom by default.
3. What Effect Does java.security.egd Have?
When we make our first call to read bytes from SecureRandom we cause it to initialize and read the JVM’s java.security configuration file. This file contains a securerandom.source property:
securerandom.source=file:/dev/random
Security Providers such as the default sun.security.provider.Sun read this property when initializing.
When we set our java.security.egd JVM property, the Security Provider may use it to override the one configured in securerandom.source.
Together, java.security.egd and securerandom.source control which entropy gathering device (EGD) will be used as the main source of seed data when we use SecureRandom to generate random numbers.
Up to Java 8, we find java.security in $JAVA_HOME/jre/lib/security, but in later implementations, it’s in $JAVA_HOME/conf/security.
Whether or not the egd option has any effect depends on the Security Provider’s implementation.
4. What Values Can java.security.egd Take?
We can specify java.security.egd in a URL format with values such as:
- file:/dev/random
- file:/dev/urandom
- file:/dev/./urandom
Whether this setting has any effect, or any other value makes a difference, depends on the platform and the version of Java we’re using, and how our JVM’s security has been configured.
On Unix-based operating systems (OS), /dev/random is a special file path that appears in the filesystem as a normal file, but reads from it actually interact with the OS’s device driver for random number generation. Some device implementations also provide access via /dev/urandom and even /dev/arandom URIs.
5. What’s So Special About file:/dev/./urandom?
First, let’s understand the difference between the files /dev/random and /dev/urandom:
- /dev/random gathers entropy from various sources; /dev/random will block until it has enough entropy to satisfy our read request with unpredictable data
- /dev/urandom will derive pseudo-randomness from whatever is available, without blocking.
When we first use SecureRandom, our default Sun SeedGenerator initializes.
When we use either of the special values file:/dev/random or file:/dev/urandom, we cause the Sun SeedGenerator to use a native (platform) implementation.
Provider implementations on Unix may block by still reading from /dev/random. In Java 1.4, some implementations were discovered to have this issue. The bug was subsequently fixed under Java 8’s JDK Enhancement Proposal (JEP 123).
Using a URL such as file:/dev/./urandom, or any other value, causes the SeedGenerator to treat it as the URL to the seed source we want to use.
On Unix-like systems, our file:/dev/./urandom URL resolves to the same non-blocking /dev/urandom file.
However, we don’t always want to use this value. On Windows, we don’t have this file, so our URL fails to resolve. This triggers a final mechanism to generate randomness and can delay our initialization by around 5 seconds.
6. The Evolution of SecureRandom
The effect of java.security.egd has changed through the various Java releases.
So, let’s see some of the more significant events that impacted the behavior of SecureRandom:
- Java 1.4
- Java 5
- Fix for JDK-4705093
- Adds NativePRNG algorithm to respect the java.security.egd setting, but we need to manually configure it
- If SHA1PRNG is used, then it may block if we use anything other than file:/dev/urandom. In other words, it may block if we use file:/dev/./urandom
- Java 8
- Java 9
Understanding how SecureRandom has changed gives us an insight into the likely effect of the java.security.egd property.
7. Testing the Effect of java.security.egd
The best way to be certain of the effect of a JVM property is to try it. So, let’s see the effect of java.security.egd by running some code to create a new SecureRandom and timing how long it takes to get some random bytes.
First, let’s create a JavaSecurityEgdTester class with a main() method. We’ll time our call to secureRandom.nextBytes() using System.nanoTime() and display the results:
public class JavaSecurityEgdTester {
public static final double NANOSECS = 1000000000.0;
public static void main(String[] args) {
SecureRandom secureRandom = new SecureRandom();
long start = System.nanoTime();
byte[] randomBytes = new byte[256];
secureRandom.nextBytes(randomBytes);
double duration = (System.nanoTime() - start) / NANOSECS;
System.out.println("java.security.egd = " + System.getProperty("java.security.egd") + " took " + duration + " seconds and used the " + secureRandom.getAlgorithm() + " algorithm");
}
}
Now, let’s run a JavaSecurityEgdTester test by launching a new Java instance and specifying a value for the java.security.egd property:
java -Djava.security.egd=file:/dev/random -cp . com.baeldung.java.security.JavaSecurityEgdTester
Let’s check the output to see how long our test took and which algorithm was used:
java.security.egd=file:/dev/random took 0.692 seconds and used the SHA1PRNG algorithm
Since our System Property is only read at initialization, let’s launch our class in a new JVM for each different value of java.security.egd:
java -Djava.security.egd=file:/dev/urandom -cp . com.baeldung.java.security.JavaSecurityEgdTester
java -Djava.security.egd=file:/dev/./urandom -cp . com.baeldung.java.security.JavaSecurityEgdTester
java -Djava.security.egd=baeldung -cp . com.baeldung.java.security.JavaSecurityEgdTester
On Windows using Java 8 or Java 11, tests with the values file:/dev/random or file:/dev/urandom give sub-second times. Using anything else, such as file:/dev/./urandom, or even baeldung, makes our tests take over 5 seconds!
See our earlier section for an explanation of why this happens. On Linux, we might get different results.
8. What About SecureRandom.getInstanceStrong()?
Java 8 introduced a SecureRandom.getInstanceStrong() method. Let’s see how that affects our results.
First, let’s replace our new SecureRandom() with SecureRandom.getInstanceStrong():
SecureRandom secureRandom = SecureRandom.getInstanceStrong();
Now, let’s run the tests again:
java -Djava.security.egd=file:/dev/random -cp . com.baeldung.java.security.JavaSecurityEgdTester
When run on Windows, the value of the java.security.egd property has no discernible effect when we use SecureRandom.getInstanceStrong(). Even an unrecognized value gives us a fast response.
Let’s check our output again and notice the under 0.01 seconds time. Let’s also observe that the algorithm is now Windows-PRNG:
java.security.egd=baeldung took 0.003 seconds and used the Windows-PRNG algorithm
Note that the PRNG in the names of the algorithms stands for Pseudo-Random Number Generator.
9. Seeding the Algorithm
Because random numbers are used heavily in cryptography for secure keys, they need to be unpredictable.
So, how we seed our algorithms directly affects the predictability of the random numbers they produce.
To generate unpredictability, SecureRandom implementations use entropy gathered from accumulated input to seed their algorithms. This comes from IO devices such as mice and keyboards.
On Unix-like systems, our entropy is accumulated in the file /dev/random.
There’s no /dev/random file on Windows. Setting -Djava.security.egd to either file:/dev/random or file:/dev/urandom causes the default algorithm (SHA1PRNG) to seed using the native Microsoft Crypto API.
10. What About Virtual Machines?
Sometimes, our application may be running in a virtual machine that has little or no entropy gathering in /dev/random.
Virtual machines have no physical mouse or keyboard to generate data, so the entropy in /dev/random accumulates much more slowly. This may cause our default SecureRandom call to block until there is enough entropy for it to generate an unpredictable number.
There are steps we can take to mitigate this. When running a VM in RedHat Linux, for example, the system administrator can configure a virtual IO random number generator, virtio-rng. This reads entropy from the physical machine that it’s hosted on.
11. Troubleshooting Tips
If our application hangs when it, or its dependencies, generates SecureRandom numbers, consider java.security.egd — in particular, when we run on Linux, and if we’re running on pre-Java 8.
Our Spring Boot applications often use embedded Tomcat. This uses SecureRandoms to generate session keys. When we see Tomcat’s “Creation of SecureRandom instance” operation taking 5 seconds or more, we should try different values for java.security.egd.
12. Conclusion
In this tutorial, we learned what the JVM property java.security.egd is, how to use it, and what effect it has. We also discovered that its effects can vary based on the platform we’re running on, and the version of Java we’re using.
As a final note, we can read more about SecureRandom and how it works in the SecureRandom section of the JCA Reference Guide and the SecureRandom API Specification and be aware of some of the myths about urandom.
As usual, the code can be found over on GitHub.
