i'm running short of time i hoped for a longer, proper discussion.
#1 is still best, until persistence is available.
in addition, either rngd or haveged should also be started, in that
preferred order, to further improve the entropy in both blocking and
non-blocking pools once init has completed, and continue to do so
while either pool is less than full and at the wake threshold.
---
tech stuffs:
for now, let's consider the state of entropy at entry, during init,
and at init complete. further more, we'll be considering the
1. at kernel entry, we have three pools all uninitialized (zero
entropy). the input pool, the nonblocking pool (urandom), and the
blocking pool.
-
http://lxr.free-electrons.com/source/drivers/char/random.c?v=3.14#L1258
2. still before init, the random pools are initialized. this includes
"device randomness", however robust or non-existent it may be. at one
point in time, no longer in 3.14, RDRAND may have been called to seed
the pools as well. currently i don't know of any hardware noise
sources directly credited to pools, as this is best left to a
userspace entropy daemon to verify the source works correctly before
using to fill entropy pools.
3. now we get to init, where the script in question lives. as
discussed, there may be useful device entropy that we don't want to
clobber. NOTE: writing to /dev/urandom or /dev/random are equivalent -
the added entropy is mixed into both pools. that is, writes to either
special character device leads to random_write();
-
http://lxr.free-electrons.com/source/drivers/char/random.c#L1493
CORRECTION: before i suggested reading from urandom and combining this
back with the start-up entropy sources - the intent was to preserve
the entropy estimates (not deplete entropy that may be needed),
however, just writing to the entropy devices does not credit back any
entropy. in short, my recommendation is: date +%s.%N + a publicly
known value. as you're not adding any entropy to the system by doing
this, just mixing the pools. adding entropy must be called with a
specific ioctl to "credit entropy bits".
-
http://lxr.free-electrons.com/source/drivers/char/random.c#L594
4. run rngd, if available. this will provide the best source of
entropy if there is a /dev/hw_random available.
5. if rngd cannot be run, launch haveged.
INIT COMPLETE: at this point, all of the entropy pools are well seeded
and mixed. in addition, one of either rngd or haveged should also be
running, which should begin the process of filling the blocking and
non-blocking pools with entropy.
last but not least, regarding rngd or haveged - both of these are
usually configured to write to the /dev/random, and both the blocking
and non-blocking pools are updated with new entropy. in other words,
if either haveged or rngd is running, urandom should always trend
toward full entropy, along with /dev/random.
-
http://lxr.free-electrons.com/source/drivers/char/random.c?v=3.14#L1390
hopefully more soon,
