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

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.