Wanting a better random seed than Java's default (presumably just current time), I was reading bytes from /dev/urandom. However, after the latest host19 reboot the seed was the same as previously. I think I had heard somewhere that /dev/random wasn't reliable under UML, so I thought urandom might be better because it should carry some state from reboot to reboot. Should I have a cron job that periodically saves the urandom state in case of unexpected reboots? Should I really be using /dev/random?

The difference between /dev/random and /dev/urandom is that /dev/random uses system event timings (disk i/o and network interrupts on a Linode) as its source of randomness but it will block if there is insufficient entropy available to satisfy a request for random data. /dev/urandom will never block, but if /dev/random has insufficient entropy, it will utilize a pseudo-random number generator to create at least enough entropy to satisfy the current request for data.

The reason that /dev/random is considered by some to be unreliable under UML is that it is quite common for it to run out of entropy and block a request for random data. This can leave the requesting process waiting until something happens to generate more entropy. In fact, this problem occurs with all headless systems due to the lack of keyboard and mouse events, which are the most active entropy sources. It may be marginally worse under UML because additional buffering of disk and network i/o further reduces entropy generation.

Obviously, when a Linode shuts down unexpectedly, the urandom PRNG seed does not get saved and at the next boot the previously saved seed is reused. This could become a problem, because /dev/random is particularly heavily used just after boot as things like mod_ssl initialise themselves and request random data, so programs that use /dev/random might block, while those that use /dev/urandom might use predictable data since /dev/random has no entropy and /dev/urandom is reusing an old seed. However, my Linode uses /dev/random for all its random data needs and never seems to block. The only precaution I have taken is to increase the entropy pool size - most distros have a default entropy pool size of 512 bytes - I increase mine to 8k so as to save up randomness during normal operations for the times when sshd and mod_ssl need lots and there's not much else going on to generate it.

To fix it now:

fremont root # echo 8192 > /proc/sys/kernel/random/poolsize

To change it automatically at boot, add the line:

kernel.random.poolsize = 8192

to /etc/sysctl.conf .

Saving the PRNG seed periodically with a script to guard against reusing the previous seed in the event of unexpected shutdown only partially mitigates the problem. After a save, the urandom PRNG will generate pseudorandom numbers starting with the saved seed. Following an unexpected shutdown, it will generate the same pseudorandom sequence again.

I recommend using /dev/random with the mods above. If you have problems with it blocking shortly after boot, switch to /dev/urandom. If you do use urandom and you believe reuse of previously saved seeds is a security risk, use a boot script to overwrite the saved PRNG seed with a value obtained from /dev/random. That way, as long as /dev/random had some entropy at some time before an unexpected shutdown, you won't reuse the previously saved seed. Unless the NSA are trying to break into your Linode, this is probably overkill.

_________________
/ Peter