That lead to this analysis paper about everything you ever wanted to know about how the Linux RNG works, its security assumptions and precautions for backward and forward security. Particularly of interest is info on reusing urandom output as a seed on next boot:
herefore, the designer of the Linux PRNG recommends ascript which, at shutdown, generates data from/dev/urandomand saves it in a file, and at startup, writes the saved data to/dev/urandom. This mixes the same data into the blocking and nonblocking pools without increasing their entropy counters.Such a script is provided in the default installation of most Linux distributions. In situations where this procedure is not possible, for example in Live CD systems, the nonblocking random number generator should be used with caution directly after the boot process since it might not contain enough entropy
This is how it is implemented with systemd. Only useful if system had a clean shutdown:
^^ On why seeds are absolutely important to RNG security:
The thing to remember about PRNGs is that they are not random . They are entirely deterministic. If one knows the initial input values and the particular PRNG algorithm, one can determine every single future “random” output value.
In this case, the algorithm is well known. It is after all, published as part of an open source kernel. So the key to randomness is the seed . The level of “randomness” that is provided is unpredictability , from one output to the next. Knowing the algorithm and the previous outputs but not the seed, it is unfeasibly hard to predict what the next random output will be. (This is not a formal nor a complete definition of what it means for a PRNG to be cryptographically secure ; but will do as a limited approximation for the purposes of this answer.)
This is the basic reason for the widely-discussed problems with Linux’s
/dev/urandom, which I am just going to gloss over here. At bootstrap, the seed is also well known. The random outputs are all entirely predictable until the PRNG is re-seeded , i.e. supplied with a fresh seed that is unique (or as near as one can get) to that run of that operating system installation, for the first time.
Great info on early boot entropy seeding, especially problematic on amnesic systems. twuewand is a neat workaround that is unfortunately not packaged for Debian but is small enough:
In the meantime until we can convince upstream to disable hwrng trust on boot which they probably won’t accept until the changes by Linus in 5.4 are in the stable kernel, we should try to drown out the untrusted input as much as possible by installing as many entropy solutions as possible.
This is gold! Thank you!