Re: Yet another updated entropy patch

[Marcus Brinkmann]

At Fri, 20 Jul 2007 18:53:05 +0200,
Thomas Schwinge <tschwinge@gnu.org> wrote:
> On Thu, Jul 19, 2007 at 01:52:39AM +0200, Marcus Brinkmann wrote:
> > At Thu, 19 Jul 2007 01:40:12 +0200,
> > Thomas Schwinge <tschwinge@gnu.org> wrote:
> 
> > What do you perceive as the benefit of having the entropy mixing
> > function outside of the device framework in its own user space server?
> 
> Having rather complex mathematical permutations done in kernel-space in a
> micro kernel system seemed rather counterintuitive for me.
> 
> But if you now say these permutations are not done in the kernel, but in
> the device framework (where the entropy is ``generated'') then it's
> starting to make some sense to me.
> 
> Do you -- in essence -- say that every (suitable) device does also (apart
> from its usual expected device functionality) fulfil a `get-entropy'
> interface?

I think that entropy collection and first-round mixing should be
completely internal to the whole device framework.  Entropy gathering
and mixing is a horizontal activity that does not easily lend itself
to vertical separation into components.  I mean this in a similar
fashion that suspend and hibernation are horizontal, whole-system
activities.

It could be different if we had a good single entropy source in every
computer.  Unfortunately, entropy devices are a rarity.  This may
change in the future, but for now we have to understand that the way
we collect entropy in PCs is a rather crude work around.  I think that
exposing the mechanics of this work around in a public interface would
be a mistake.

(I should add that the other side of the story is that a single
entropy device can fail, and failure is hard to detect.  In that case,
our crude work around would probably outperform the failed device,
which may be a reason to also stick to the work around in addition to
a random device if that is available).

> And do you say that -- because all device drivers are anyway
> running in kernel space these days -- all devices' entropy is aggregated
> into (currently) one entropy buffer?

This is essential.  The "entropy sources" in the PC we are talking
about are much, much too weak already.  Splitting into more than one
buffer is not good.

The single buffer can then be demultiplexed into multiple pools of
different quality.  This is also important, because session keys
should not drain the high quality random pool, but taken from some
long-phased pseudo random generator that is reseeded once in a while
(/dev/urandom).  Maybe there should even be more levels than two.
Again, this is horizontal, because the available entropy has to be
redistributed according availability.  For example, surplus entrop
could benefit all pools.

> If we (one day) would have several
> independent device driver protection domains (in user space), would each
> of them then provide their own entropy source?

I would leave this problem internal to the device framework.

Don't let yourself be distracted by the complex mathematical formulas.
These formulas are supposed to be carefully chosen and implemented and
should not change very often.  Probably less often than your hardware.
In the limit, they should be as static as any other cryptographic
algorithms, for example DSA or SHA1.

Thanks,
Marcus