Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 18 Aug 2013 12:27:58 -0700
From:      Tim Kientzle <tim@kientzle.com>
To:        Mark R V Murray <mark@grondar.org>
Cc:        =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= <des@des.no>, secteam@freebsd.org, FreeBSD-arch Arch <freebsd-arch@freebsd.org>
Subject:   Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion
Message-ID:  <932AB5CA-778E-438D-8FD3-8C0F29F3D117@kientzle.com>
In-Reply-To: <537622E1-F785-4BFA-B829-09DCDB484606@grondar.org>
References:  <20130807183112.GA79319@dragon.NUXI.org> <86pptfnu33.fsf@nine.des.no> <20130815231713.GD76666@x96.org> <20130816002625.GE76666@x96.org> <9B274F48-0C88-4117-BEAC-1A555772A3C5@grondar.org> <86a9kf733d.fsf@nine.des.no> <0C97B866-A169-4141-8368-AA7F5B5382F4@grondar.org> <861u5r71zi.fsf@nine.des.no> <892B11BD-396D-4F82-B97C-753F72CA494D@grondar.org> <86r4dr5j3p.fsf@nine.des.no> <4C1BD77C-8C6B-4044-9285-5978A3BC4B70@kientzle.com> <537622E1-F785-4BFA-B829-09DCDB484606@grondar.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Aug 18, 2013, at 10:20 AM, Mark R V Murray wrote:

>> Users could compile the null mixer into the kernel
>> and load a single HW RNG driver to have precise
>> control over /dev/random.  Interrupt harvesting would
>> be the lowest-quality source as a fall back.
> 
> There are lots of harvest points in the kernel. Why not
> take the lot?

I think everyone agrees that the GENERIC kernel
should use Yarrow or Fortuna to mix the available
entropy sources.

But clearly some people really want to be able to
force /dev/random to be the unconditioned output
of a particular HW RNG.  I don't know if this is a
good idea or not, but clearly there are people who
want this.

I think my proposed "null mixer" is a reasonably simple
way to allow that.  (Should probably call it a "passthrough
mixer" rather than "null.")

And I think it does so in a way that doesn't introduce
horrible failure modes.

>> In particular, this has a reasonable failure mode if
>> someone built a kernel with only a single HW entropy
>> source and the null mixer:
>> * On hardware with that source, they would get
>>    full-speed HW entropy.
> 
> OK. Works for me. This is me accepting a point and
> changing my stance.
> 
> This will need to be written.

Yes, the "passthrough mixer" would need to be written
as an alternative to Yarrow or Fortuna.

My key claims:
  * Entropy mixers such as Yarrow, Fortuna, or
     passthrough are different from entropy sources.
     Mixers specify how /dev/random is generated from
     available entropy.

  * It makes sense to only allow one mixer in a particular
     kernel.  That could be done via kernel options; I suppose
     it could be done as device modules but only one of
     them can actually own /dev/random.

  * It makes sense to access HW RNGs via device modules
    and to allow any number of them to be loaded and active
    at the same time.

The above provides a good answer for GENERIC
(Yarrow/Fortuna mixing all available entropy).

The above also allows people to build custom kernels
that connect a single entropy source to /dev/random
without having horrible failure modes.

>> * On hardware without that source, they would get
>>    the old blocking /dev/random that we had before
>>    Yarrow, the one that used only interrupt harvesting.
> 
> Disagree. The fallback should be Yarrow/Fortuna. Both
> do a better job with the same input.

I agree Yarrow/Fortuna are better.

But some people really want to only have their preferred
HW RNG and are going to demand that Yarrow/Fortuna
not be compiled in if they don't need it.  For example, some
embedded processors are starting to get HW crypto; a
passthrough mixer plus HW RNG could be significant
code savings compared to Yarrow or Fortuna.

I am NOT claiming the old blocking /dev/random is
"good"; just that it is not an entirely unacceptable failure
mode for badly mismatched kernel/hardware combinations.
Keep in mind such mismatches may happen accidentally:
add-on HW RNG cards can fail.

Tim




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?932AB5CA-778E-438D-8FD3-8C0F29F3D117>