Date: Sun, 18 Aug 2013 21:02:46 +0100 From: Mark R V Murray <mark@grondar.org> To: Tim Kientzle <tim@kientzle.com> 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: <F908BF80-538B-4363-ACCC-3D860CBEE359@grondar.org> In-Reply-To: <932AB5CA-778E-438D-8FD3-8C0F29F3D117@kientzle.com> 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> <932AB5CA-778E-438D-8FD3-8C0F29F3D117@kientzle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_7C17E4A6-416E-4235-9325-B1156A587A18
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=windows-1252
On 18 Aug 2013, at 20:27, Tim Kientzle <tim@kientzle.com> wrote:
>
> 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.
Not sure about the "everyone agrees", but I would like
it to be so!
> 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.
Agreed. (This includes my change of position on the
subject.)
Others want Yarrow/Fortuna no matter what.
> 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.
Well, I haven't seen it, but if it is something like
the ivy.c driver, then yes. This presumes that the Ivy/
Bull Mountain 'rdrand' instruction is safe, which I will
presume.
The ivy.c and nehemiah.c drivers could use some
abstraction, and I suspect (and hope!) this is what
you rate talking about. :-)
>>> 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.
OK.
> 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.
Yes!
> * 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.
OK; "One active" can own /dev/random, in the sense that (say)
Yarrow and Fortuna may be present, but only one is active, and
switching between the two takes an active decision from the
machine's admin.
> * 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.
Yes. But if there is no mixer, which "wins"?
> The above provides a good answer for GENERIC
> (Yarrow/Fortuna mixing all available entropy).
OK.
> The above also allows people to build custom kernels
> that connect a single entropy source to /dev/random
> without having horrible failure modes.
Agreed. In all cases, understanding (or lack thereof)
of failure modes needs to be at least discussed. Yarrow
and Fortuna have well-known cryptographers designing
them, and their source (is|will be) available. For
this, RDRAND, etc awareness of relevant attacks needs
to be made public. For less well-known hardware, we
need to ensure that problem areas are known.
>>> * 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.
Thanks :-) :-D
> 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.
Ok. NP.
> 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.
True. Yarrow and Fortuna were designed to shield against
those very failure modes. They treat ALL entropy sources
as suspect and endeavour to be secure irregardless.
I propose two-route device:
Route 1 (SW):
Yarrow/Fortuna (choosable between the two for now),
and a fallback for Route 2. It should be possible to
build a kernel without this route.
Route 2 (HW):
Minimally-processed randomness directly from a dedicated
source, similar to the rdrand/ivy device, but with the
actual source abstracted. If no suitable source is
available, then this whole route fails. This is where
some useful "pluggability" can come. If this fails to
fall back; then perhaps a "I don't care" vs "PANIC!!"
fallback can be supplied. Here lie the dragons.
M
--
Mark R V Murray
--Apple-Mail=_7C17E4A6-416E-4235-9325-B1156A587A18
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.20 (Darwin)
Comment: GPGTools - http://gpgtools.org
iQCVAwUBUhEoct58vKOKE6LNAQqGegP+I1pycNcb6e/es79rNVqO5TVKBynie/7i
brhPhWwwHuXbz+G97Q8fzsUW/B/GNzNRFRy5d+Dp6nGEo1l+746Fdh70yG9FOPNk
tghAl1FlL6RbhkBYOQZJ8wUIW/Py19igutqn4mj+IF4Iq9l+1YYNCwz74VWWXafl
9rtPT/iQTVU=
=hzeq
-----END PGP SIGNATURE-----
--Apple-Mail=_7C17E4A6-416E-4235-9325-B1156A587A18--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F908BF80-538B-4363-ACCC-3D860CBEE359>