Comment 109 for bug 62751

It's a long story that depends on how you define "random" and
"secure". And this is really the wrong forum for this question and
answer. But I'll give it a whack anyway. :-)

/dev/random never hands out more bits than it has entropy available.
(It collects entropy from the timings of keyboard interrupts, mouse
interrupts, and the like; and it tries to conservatively estimate how
many bits of randomness each event adds to the pool.) If the entropy
estimator is conservative -- which its creators believe but which is
impossible to prove -- then /dev/random is perfectly random and
perfectly secure, in the sense that, from an attacker's point of view,
any one of the 2^N possible strings of N bits is equally likely to be
output.

/dev/urandom hands out as many bits as you ask for, using the truly
random state of /dev/random as a seed for a cryptographic
pseudo-random number generator (PRNG). So even if the /dev/random
entropy pool only has (say) 256 bits of entropy, /dev/urandom will
gladly give you 1000, 1 million, or 1 billion bits of output. In this
example, since there are only 256 bits of entropy, there are only
2^256 possible outputs, so each of the 2^1000, 2^(1 million) or 2^(1
billion) possible outputs from /dev/urandom is NOT equally likely. In
this sense, /dev/urandom is "less secure" than /dev/random. If the
PRNG is cryptographically strong -- which its creators believe but
which is impossible to prove (at present) -- then there is no
*practical* way to distinguish the output of /dev/random from that of
/dev/urandom... Because for practical purposes, 2^256 might as well
be 2^1000.

The point of preserving the entropy pool across reboots is to give the
entropy pool an initial state that is unknown to any attacker. In
other words, even if the attacker knows a lot about your system --
like what state it is in when you first turn it on -- he will not know
anything about your entropy pool as long as he does not know what is
in the saved state file.

Does this help?