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

[Mark R V Murray]

On 18 Aug 2013, at 12:33, Dag-Erling Smørgrav <des at des.no> wrote:

> Mark R V Murray <mark at grondar.org> writes:
>> OK - in the context of what is currently there, it makes less sense than
>> that; loading RDRAND/Ivy and Nehemiah simultaneously is silly because
>> they are different architectures, and only one can ever work on a particular
>> box; so what happens is some script selects the wrong one? I suppose
>> the probe is there to prevent this.
> 
> I don't know offhand whether we support them, but there are discrete
> HWRNGs which might be present alongside an on-die HWRNG; and in all
> cases, Yarrow and / or Fortuna may be present in the kernel alongside a
> supported HWRNG.

We do support them; I sent a list. Its a black/white choice; either they
get used as Yarroow source data, or they are straight /dev/random drivers,
not both.

>> We still have the anachronism where the older hardware RNGs are turned
>> into /dev/random devices and the newer ones supply their entropy to
>> the software (Yarrow) for further processing.
> 
> Provided the HWRNG is of sufficient quality, the user should be allowed
> to use it directly (through /dev/random) without Yarrow / Fortuna.  At
> the same time, we do not want to lose the ability to feed their output
> to Yarrow / Fortuna.  Plugging all {P,HW}RNGs into a common framework
> makes it *easier*, not *harder*, to support both options.

The current code does not address that, but happens to be a useful, if
small, step in getting That does not appear to be part of the design,
rather a useful accident.

M
-- 
Mark R V Murray

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 353 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20130818/ebd737db/attachment.sig>