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

[Mark R V Murray]

On 8 Aug 2013, at 20:25, Warner Losh <imp at bsdimp.com> wrote:

> 
> On Aug 8, 2013, at 7:01 AM, Andrey Chernov wrote:
> 
>> Many years ago I already suggest to de-modularize random (making it not
>> optional), with fallback to yarrow if hardware RNGs can't be probed or
>> not configured.
> 
> I think that the 'fallback to yarrow' is necessary here.

My current inclination is to make Yarrow the basic device (or "Fortuna Lite", but that is a problem for MUCH later), and make the hardware devices feed Yarrow, if they are present.

Fortuna will then be an optional replacement for Yarrow, and it will keep the ability to source input from hardware RNGs if they are present.

I still want to get back something like the original get_cyclecount(); simple and quick. I don't care what its called, but out doesn't need to be the massive thing that the current get_cyclecount() has grown to be on x86. rdtsc(), I think it was.

> P.S. Where 'yarrow' can easily be read as 'the best software RNG we've implemented' should that change to something better in the future.

While Fortuna matures, I'd like to keep it as an option, not make it a replacement.

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/20130808/11bdbd87/attachment.sig>