On 02 Aug (22:01:07), coderman wrote:
> 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.
I confirm. RDRAND (or any arch specific hw rng) is actually not mixed
anymore in the entropy pool. There was too much concerns on the security
of relying on the hw RNG thus it's now an exported symbol in the kernel
and *not* used anywhere.
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/char/random.c?id=refs/tags/v3.15.8#n1216
>
> 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.
I asked a friend of mine working for Canonical asking him how they do
things with Ubuntu images.
He told me that they can't use haveged since it's only good to
*increase* your entropy pool and rngd is useless without an hardware
RNG. Their big issue is the Ubuntu Cloud Image for which they rely on
https://launchpad.net/pollinate, TL;DR; it fetches random bytes over
HTTPS to seed /dev/random. (They do pin the certificate in the client
which is less crazy :).
See:
http://blog.dustinkirkland.com/2014/02/random-seeds-in-ubuntu-1404-lts-cloud.html
To be honest, I don't have a good way of fixing this issue. Feeding the
urandom-seed with the date might be better than nothing but again I
think that if a NTP correction occurs before seeding it, an attacker
could end up knowing the seed if the NTP server or the link is
malicious.
Is it crazy to think that Tails could provide a "seeding server" and use
pollinate?
Cheers!
David
>
> 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,
