Random number and Entropy pool strategy on JVM

In Apache-tomcat Official document: How to get Tomcat to start faster there are some optimizations at startup, one of which is the "entropy source" (entropy source) strategy used when generating random numbers.

He mentions that TOMCAT7 's session ID is generated mainly by java.security.SecureRandom generating random numbers, and the random number algorithm uses "SHA1PRNG"

private String secureRandomAlgorithm = "SHA1PRNG";

In Sun/oracle's JDK, the provider of this algorithm relies on the random data provided by the operating system at the bottom, on Linux, and /dev/random /dev/urandom , for the description of the two device blocks, has also been discussed in the random number of articles, Wiki has a more detailed description, Excerpt, look first /dev/random :

On reading, the/dev/random device returns random bytes that are less than the total entropy pool noise. /dev/random can generate a high-randomness public key or one-time cipher book. If the entropy pool is empty, the read operation on the/dev/random will be blocked until sufficient ambient noise is collected.

The other /dev/urandom is a non-blocking generator:

A copy of the Dev/random is/dev/urandom ("unlocked", a non-blocking random number generator) that reuses the data in the entropy pool to produce pseudo-random data. This means that the read operation on the/dev/urandom is not blocked, but its output entropy may be less than/dev/random. It can be used as a pseudo-random number generator for generating lower strength passwords and is not recommended for generating strong long-term passwords.

In addition, the wiki also mentions why the random number generator in the Linux kernel uses the SHA1 hashing algorithm rather than the encryption algorithm to avoid legal risk (password export restrictions).

Back to the recommendations in the Tomcat documentation, use a non-blocking entropy source (entropy source), set by the Java System Properties:

-Djava.security.egd=file:/dev/./urandom

This system attribute EGD represents the Entropy collection daemon (entropy gathering daemon), but why is this value dev added to and random between the points? is because of a JDK bug, in the connection of this bug someone feedback in time to Securerandom.source set for /dev/urandom It also still use /dev/random , someone provides a workaround, One of the workarounds is to set the Securerandom.source to be the /dev/./urandom only line. Some people commented that this is not a bug, it is intentional.

I looked at the Jdk7 java.security file that I am currently using, and the configuration is still used /dev/urandom :

## Select the source of seed data for SecureRandom. By default an# attempt is made to use the entropy gathering device specified by# the securerandom.source property. If an exception occurs when# accessing the URL then the traditional system/thread activity# algorithm is used.## On Solaris and Linux systems, if file:/dev/urandom is specified and it# exists, a special SecureRandom implementation is activated by default.# This "NativePRNG" reads random bytes directly from /dev/urandom.## On Windows systems, the URLs file:/dev/random and file:/dev/urandom# enables use of the Microsoft CryptoAPI seed functionality.#securerandom.source=file:/dev/urandom

I'm not sure Jdk7, this is the same as in the /dev/urandom bug report, /dev/random to use the non-blocking entropy pool, here or to modify it, /dev/./urandom or jdk7 has fixed the problem, that is, the meaning of the comments, have to verify.

Use the code given in the bug report:

import java.security.SecureRandom;class JRand {public static void main(String args[]) throws Exception {System.out.println("Ok: " +SecureRandom.getInstance("SHA1PRNG").nextLong());}}

Then set different system properties to verify, first on my Mac:

% time java -Djava.security.egd=file:/dev/urandomJRandOk: 8609191756834777000java -Djava.security.egd=file:/dev/urandom JRand0.11s user 0.03s system 115% cpu 0.117 total% time java -Djava.security.egd=file:/dev/./urandomJRandOk: -3573266464480299009java -Djava.security.egd=file:/dev/./urandom JRand0.11s user 0.03s system 116% cpu 0.116 total

Can see /dev/urandom and /dev/./urandom the execution time is similar, a little puzzled, and then take a closer look at the wiki said:

The FreeBSD operating system implements a variant of the 256-bit Yarrow algorithm to provide pseudo-random number streams. Unlike Linux's/dev/random, FreeBSD's/dev/random does not clog, similar to Linux's/dev/urandom, and provides cryptography-safe pseudo-random number generators instead of entropy pools. The/dev/urandom of FreeBSD is simply linked to the/dev/random.

Although not a link on my Mac, the /dev/urandom /dev/random mac and the BSD kernel should be similar and /dev/random non-blocking, compatible with the /dev/urandom Linux system, and the behavior of the two random number generators is consistent. Refer here.

Then test on an Ubuntu system:

% time java -Djava.security.egd=file:/dev/urandomJRandOk: 6677107889555365492java -Djava.security.egd=file:/dev/urandom JRand0.14s user 0.02s system 9% cpu 1.661 total% time java -Djava.security.egd=file:/dev/./urandomJRandOk: 5008413661952823775java -Djava.security.egd=file:/dev/./urandom JRand0.12s user 0.02s system 99% cpu 0.145 total

This time the difference is fully manifested, the blocking mode of the entropy pool takes 1.6 seconds, and the non-blocking mode is only 0.14 seconds, the difference is an order of magnitude, of course, the cost is converted to CPU overhead.

Added, after several successive tests on Ubuntu /dev/random , the entropy pool was empty and blocked for about 60 seconds. Application server side to avoid this way.

Http://www.th7.cn/Program/java/201406/226039.shtml

Random number and Entropy pool strategy on JVM