On Tue, Dec 05, 2006 at 05:59:48PM +0000, Christos Zoulas wrote:
> In article <45752678.2010001@uj.ac.za>, Yorick Hardy  <yhardy@uj.ac.za> wrote:
> >ID Quantique have a quantum random number generator
> >
> > http://www.idquantique.com/products/quantis.htm
> >
> >which includes drivers for FreeBSD.
> >
> >I adapted the drivers for NetBSD:
> > 
> > http://issc.uj.ac.za/~yorick/quantis_netbsd.tar.bz2
> >
> >Can anyone comment or make suggestions?
> >Can or should the driver support rnd(9)?
> 
> I think that it should support rnd(9) look at the hifn7751 or the amdpm
> driver in sys/dev/pci.
> 
> Also you should KNF the driver. The copyright in the common sources looks
> BSD'ish but the other files don't have any copyrights.

If you have design documentation for the RNG, pay careful attention to
what hifn7751.c does in order to ensure that the entropy estimate for
the kernel random pool is good -- it was rewritten from the Hifn design
docs with help from Hifn because it was clear that the original code was
not doing this right.

In particular:
	1) Many RNGs have a warm-up time before they produce the designed
	   amount of entropy per output bit.  Don't feed bits into the
	   kernel pool until you know this time has passed.

	2) Some RNGs do not actually guarantee that successive reads give
	   data that are actually represent different samples from whatever
	   means is used to digitize the underlying source (for example,
	   the hifn 7[79]xx do not, because of a design mistake).  If this
	   is the case, you must ensure that you do not sample them faster
	   than _they_ sample the random data.  The workaround in the Hifn
	   driver is ugly, but sufficient (it would be more efficient to
	   wait, but waiting _between device reads_ in the callout is not
	   so easy to do).

	3) With design documentation it is usually possible to determine a
	   worst-case estimate for bits of underlying source entropy per
	   output bit of the hardware generator.  In this case, you want
	   to be sure that you feed the random pool enough generator
	   output at once to ensure that you can give it a valid estimate
	   of at least one bit -- see the value, and use, of
	   HIFN_RNG_BITSPER and note that if we fed the random pool less
	   than three bytes at a time, we'd be forced to estimate 0
	   entropy -- not good.

	4) Be careful, with regard to some cryptographic hardware now on
	   the market at least, that what you are feeding the random pool
	   is not actually the *output* of a cryptographic PRNG keyed from
	   a source of dubious quality (this is the case for a number of
	   'FIPS compliant' RNGs integrated into currently available
	   crypto chips).
Thor