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, _______________________________________________ Tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
