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

Richard Coleman richardcoleman at
Mon Apr 12 17:44:35 PDT 2004

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 ( but 
it doesn't mention anything about this.  Anyone know offhand?

Richard Coleman
richardcoleman at

More information about the cvs-src mailing list