Oracle Java 8 x64 for Linux and RandomSource

Question

I really thought that after about 200 or more tomcat installs on various platforms, I am ready for any kind of challenge but this one is tricky.

I created a vanilla Ubun

Answer 1

I think the answer relies in this link for WebLogic support: https://docs.oracle.com/cd/E13209_01/wlcp/wlss30/configwlss/jvmrand.html where they mention that "random" is more secure

and also in the Oracle bug comment (already mentioned by David): http://bugs.java.com/view_bug.do?bug_id=4705093

with particular regard to this part:

Because SHA1PRNG is a MessageDigest-based PRNG, it historically has always used /dev/random for initial seeding if seed data has not been provided by the application. Since all future values depend on the existing state of the MessageDigest, it's important to start with a strong initial seed.

Changing that behavior was troubling to the original developer. So he did created a new SecureRandom impl called NativePRNG, which does respect the java.security.egd value.

If you call:

• new SecureRandom() on Linux and the default values are used, it will read from /dev/urandom and not block. (By default on Solaris, the PKCS11 SecureRandom is used, and also calls into /dev/urandom.)

• SecureRandom.getInstance("SHA1PRNG") and do not specify a seed, OR new SecureRandom() but have specified an alternate java.security.egd besides "file:/dev/urandom", it will use the SHA1PRNG which calls into /dev/random and may potentially block.

• SecureRandom.getInstance("NativePRNG"), it will depend on what java.security.egd is pointing to.

Answer 2

what I understood is that /dev/random can run out of entropy (whatever this means) but perhaps it means at some point it cant generate any more random numbers).

It can temporarily run out of entropy and block until it gathers enough to dispense more. The JVM only needs a little to seed a SecureRandom instance.

How long it takes depends on how noisy your system is and how the kernel gathers entropy.

Is it sane from Oracle to rely on /dev/random when there can be corner cases where the OS cant produce any more numbers?

The lack of entropy can be problematic on embedded systems or in VMs on first boot which come with a very deterministic image, have few sources of entropy that can be harvested compared to real PCs and no RDRAND instruction or similar for the kernel to harvest for entropy pool initialization.

Insufficient randomness can be catastrophic for key generation and other cryptographic algorithms, e.g. DSA is quite sensitive to the quality of your entropy source.

So yes, it is quite sane to rather wait than having a compromised system.

To quote from Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices by N.Heninger et al.

To understand why these problem are occurring, we manually investigated hundreds of the vulnerable hosts, which were representative of the most commonly repeated keys as well as each of the private keys we obtained (Section 3.2 ). Nearly all served information identifying them as headless or embedded systems, including routers, server management cards, firewalls, and other network de- vices. Such devices typically generate keys automatically on first boot, and may have limited entropy sources com- pared to traditional PCs.

Furthermore, when we examined clusters of hosts that shared a key or factor, in nearly all cases these appeared to be linked by a manufacturer or device model. These observations lead us to conclude that the problems are caused by specific defective implementations that generate keys without having collected sufficient entropy.

If you have an external source of entropy and root privileges you can push additional entropy into the pool and increment its counter (i think rngd can do this for you). Just writing to /dev/random will add your entropy to the pool but not increase the counter.

For VMs there also are virtualization drivers to get entropy from the host.

Pointing the jvm to a hardware RNG dev (/dev/hwrng, /dev/misc/hw_random or something like that) may also be an option, if they're available.