Helping the entropy pool in a (Debian) live system

[sycamoreone]

Hi!

The Tails project is currently investigating how best to help the Linux
entropy pool with RNGs, such as haveged, rngd and ekeyd. The goal is not
to "bolt questionable fixes onto the operating systems", and it would be
very useful to get some recommendations.

One important question is which daemon should *not* dominate the other.
For example, many people apparently suggested that ekeyd should dominate
haveged. Or would we be better of if we don't ship one/some of these at
all? (Cf. the tickets below.)

Keep in mind that a live system will have to work in various hardware
configurations. Also, specifically in Tails, the entropy pool seed will
first have to get persisted in some form
(https://labs.riseup.net/code/issues/7675) and a good source of
randomness is vital for some of the use cases of the system.

My question here is not about how randomness generation should be
implemented in Linux, but rather very concretely

How should a (Debian based) live system use the tools that are
available right now?

An answers to this questions will probably be interesting not just for
the Tails project but also for other live systems and for systems
designed for virtual machines.

Any input, and especially concrete recommendations will be much appreciated!

[ Specifically for Tails the relevant tickets to look at are

https://labs.riseup.net/code/issues/5650
https://labs.riseup.net/code/issues/7102

and the related issues listed there. ]

Cheers!

[Sandy Harris]

On Friday, February 13, 2015 at 2:30:47 PM UTC-5, sycamoreone wrote:

Hi!

The Tails project is currently investigating how best to help the Linux
entropy pool with RNGs, such as haveged, rngd and ekeyd. The goal is not
to "bolt questionable fixes onto the operating systems", and it would be
very useful to get some recommendations.

Is this rng add-on of use to you?
ftp://ftp.cs.sjtu.edu.cn:990/sandy/maxwell

I designed it for approximately your use case.

[Ryan Carboni]

Personally, I suggest removing access to random except for debugging purposes to check if you didn't accidentally use one source of entropy ( https://www.schneier.com/blog/archives/2008/05/random_number_b.html ).

Don't xor the sources of entropy together, this makes it harder to check if there's problems.

Just place the entropy from each source into it's own pool.

Hash each pool and use the hash as a subkey. Hash all the hashes and use the hash as a whitening key.

Reroute any calls by non-privileged processes to random to urandom.

I'm only partially knowledgeable.

The method ought to work if the hardware is secure.