This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
My employer bought me a sweet new server with a RedHat license (we usually run our apps on Solaris). My excitement was tempered by the fact that it takes Weblogic over 10 minutes to start up. This is apparently caused by the /dev/random pool becoming exhausted and there not being enough interesting interaction with the server to replenish the pool. The workaround is to point the JVM to the /dev/urandom pool, which does not block, but which has the downside of being less, well, random.
Does anyone see this as a potential problem? Are there other alternatives?
I've not gotten deep into Weblogic, but I've done a lot of professional cryptography.
Ten seconds seems like a very long time, is it just using java.security.SecureRandom as the random source?
The reason its blocking is to get more random data, but you would have to dig deep into the RedHat source/forum to find exactly what its using. Using a non-blocking source that returns zeros when it has nothing random doesn't help your randomness, it mostly defeats the whole idea.
How secure do you have to be? For example, you could listen to the Ethernet port, and take the raw bytes, pass them through a SHA and get lots more pseudo random data. [I'll leave adding that new data into the pool as a separate discussion]. For practical uses, this is good enough. But in theory, a national-security level bad guy could pump a lot of data onto the ethernet link/segment, and therefor bias your random pool.
There is a fair amount of random data that you can pull from a $40 "gps mouse" that plugs into a USB port, as long as you can put the gps receiver near a window so it can get some sattelite view. They don't generate a lot of data, but its fairly good and dead easy to get.
Pat Farrell wrote:
How secure do you have to be? For example, you could listen to the Ethernet port, and take the raw bytes, pass them through a SHA and get lots more pseudo random data. [I'll leave adding that new data into the pool as a separate discussion].
We're talking about HTTPS for a public web site, so fairly secure. And yea, adding data into the /dev/random pool is a problem (my RedHat admin says it can't be done).
This bug indicates that I can use any URL for a seed. Maybe I'll find a good source of random data and point the JVM there. . .