random(4) plugin infrastructure for mulitple RNG in a modular fashion

[Warner Losh]

On Aug 19, 2013, at 1:13 AM, Mark R V Murray wrote:

> 
> On 19 Aug 2013, at 08:09, Warner Losh <imp at bsdimp.com> wrote:
>>> Besides Yarrow and Fortuna mixers, we could then
>>> offer a "null mixer" option that selected the single
>>> "best" entropy source and passed it directly through.
>> 
>> I'm still wondering why timecounters aren't the right model to follow here, where you can have several compiled into the kernel and the one with the best score wins.
> 
> How would they get a score, and how would it be decided which is better? How is the score "calibrated"?

For timecounters, we make judgements based on how good or bad we think the timekeeping ability of the underlying device. I'd imagine that we'd rate the hardware RNGs high, and the fallback means of harvesting entropy from interrupts medium, and anything that's really really bad as low. This would allow for the hardware RNGs to override the other sources of entropy, while still allowing fallback to reasonable entropy on devices that are known suspect (While still allowing the pig-headed and/or externally constrained folks to use the bad sources).

For the mixers, the scoring mechanism makes less sense. You'd want more of an ordered list specified by the user to dictate policy to choose between nothing, fortuna and yarrow.

You'd also want a parameter to deal with failure here: panic or block.

>>> 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.
>>> 
>>> 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.
>>> * 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.
>> 
>> Assuming there was enough interrupt entropy to generate bits…
> 
> See Ferguson & Schneier on this (qv my follow-up).

Saw that. I was worried only about starvation, but there's much more to worry about than that it seems.

Warner