cvs commit: src/sys/modules/random Makefile src/sys/dev/random randomdev.h randomdev_soft.c randomdev_soft.h yar

[Richard Coleman]

Nate Lawson wrote:

>>Yarrow's entropy accumulation and PRNG generator parts are disconnected
>>(that is part of its point), so there is no connection between the
>>number of bytes harvested and the number of bytes supplied. This
>>makes a very long armoured pipeline between accumulation and issue,
>>which seems like overkill when the suppied entropy is 99% OK (far
>>better than Yarrow currently ever gets, BTW).
>>
>>[...]
>>
>>Yarrow is unsuitable for this purpose; it is a great generator when
>>you have a low-entropy environment and you need to protect against
>>attackers having potential knowledge of the inputs.
> 
> 
> * XSTORE is an unprivileged operation, users can call it all they want.
> 
> * If your hardware fails undetectably somehow (101010101...), a
> single-source PRNG also fails.  If we seed our existing PRNG which
> accepts multiple sources, it doesn't.
> 
> I think Jacques said it best.  All I'm asking is that we use a
> well-reviewed PRNG and as many entropy sources as possible, including this
> nice VIA part.
> 
> -Nate

I agree with this sentiment.  The more crypto hardware that becomes 
available, the more of it that will be crap.

Now, the obvious question is what post-processing does OpenBSD do to 
hardware random number generators?  I read the semi-recent paper on the 
crypto framework for OpenBSD (http://www.openbsd.org/papers/ocf.pdf) but 
it doesn't mention anything about this.  Anyone know offhand?

Richard Coleman
richardcoleman at mindspring.com