[Openswan dev] Support for hardware random number generators

[David McCullough]

Jivin Vrabete, Brad lays it down ...
> >-----Original Message-----
> >From: David McCullough [mailto:David_Mccullough at securecomputing.com] 
> >Sent: 20 November 2008 11:26
> >To: Vrabete, Brad
> >Cc: dev at openswan.org; Paul Wouters
> >Subject: Re: [Openswan dev] Support for hardware random number 
> >generators
> >
> >
> >Jivin Vrabete, Brad lays it down ...
> >> Hi David,
> >> 
> >> Thanks for the insight.
> >> 
> >> I want to follow-up on what I have said about the OCF thread for 
> >> generating random numbers. What I have noticed was that on a system 
> >> with hard disk, when the disk gets accessed, the thread function is 
> >> not getting called because the entropy pool is never empty. 
> >Basically, 
> >> the function is called only once, when the OCF module starts.
> >
> >Ok,  I think what you are seeing is that OCF has filled the 
> >pool,  it will not get called again until the pool falls below 
> >a certain threshold.  At this point it will get called again.
> >
> >If you want to see this in action,  turn on OCF debug and run something
> >like:
> >
> >	dd if=/dev/random of=/dev/null
> >
> >or:
> >
> >	hd /dev/random
> >
> >Try that on a system with OCF+RNG (esp. and embedded system) 
> >and it will pretty much hang (hardly any entropy generation at all).
> >
> >With OCF+RNG,  you will get fairly high Mbps of random data.
> >
> >> I was thinking of finding a way to disable the filling entropy pool 
> >> when a HW RNG (proper one) is present. What do you think?
> >
> >All entropy is good.  The more the pool is stirred etc the 
> >better the quality of the random data.  Having disk ints and 
> >OCF or whatever adding is a good thing.
> 
> I agree; but a proper HW RNG will provide quality random data without the 3
> SHA operations performed in the kernel. Under heavy IPsec traffic, these 3
> SHA operations are getting quite a good share of the computing power
> available. One could squeeze more of an (especially embedded) IPsec box if
> these operations would not be performed. Of course, the assumption is the HW
> RNG is a proper one and provides quality random data.

Thats a fair call.  Just stub out the "add_blkdev_radomness" or whatever
the function is :-)

> >The difference is that OCF only adds to the pool when it is 
> >running low (high demand for random data),  the HD/block dev 
> >entropy just adds to it all the time.  You do not want OCF 
> >doing this or it will be constantly adding to the pool and 
> >using valuable CPU time ;-)
> >You could,  it you wanted,  mod the OCF patch to always top up 
> >the random pool.  This would be a small patch,  but as I said, 
> > it wouldn't really gain you anything.
> 
> I was thinking to leave OCF RNG thread as it is (generate random data when
> entropy pool is empty) and disable entropy generation on disk
> access/interrupts. That way OCF will generate random data only when needed.
> One could also compile out the FIPS check, if there is confidence in the
> quality of the HW RNG.

With all the RNG's I have tested so far,  the FIPS check is actually
a pretty good idea ;-)

But yes,  if you can be sure the RNG is working properly at all times
and producing good data at all times,  the FIP's check is redundant.

Cheers,
Davidm

-- 
David McCullough,  david_mccullough at securecomputing.com,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org   http://www.snapgear.com