The actual time would probably be more useful than the time since boot.

I still have a problem with what I see as a fundamental weakness in storing "randomness" across reboots.

Logically, given a sufficiently large amount of time between a crash and the subsequent reboot, one could predict the random state, and attack immediately after a reboot... just like one could guess the fortune now, following a reboot.

The state save in the shutdown -- besides not working unless you hopping on one leg, pat your head, and rub your tummy while singinging "Danny Boy" (or the moral equivalent of not being allowed to crash or use the "halt" or "reboot" commands) -- seems to me to be an inherent security flaw.

Matt's points about compromise, number of random bits, as well as the amount of time it's OK to take, are also salient.

Bottom line: any algorithm predicated only on saved state and based on predictable progression over a large period of time in which a compromise may be effected, is a problem.

Perhaps it's time to draft a "big gun"? Someone who knows enough about number theory to know that multiplying two random numbers together results in less randomness, not more?

Or perhaps it's time to use a "tried but true" algorithm, like the 48 bit linear congruential algorithm, with a polynomial preterbation based on the current time at the time of reseeding, until the random ducks get (not) in a row? Pseudorandom seeding with a hidden key has got to be better than anything that opens a computation window for as long as your system is down after a crash... after all, we _are_ talking about security through obscurity (of the next number in a pseudorandom sequence), here.

Nothing wrong with finding a handy giant, and standing on its shoulders... it's a time honored scientific tradition.

I'm not really volunteering here, since I'm just an applied mathematician, and only ever got off on theory as it applied to real problems in physics and computer science and elsewhere. I just know enough to know that it'd be dangerous to trust me to do the job 100% correctly. 8-). But I also see this as getting more important as /dev/random gets more and more central to security and authentication policy and enforcement.