[Openswan dev] Support for hardware random number generators

[Vrabete, Brad]

>-----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.


>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.

Thanks,

Brad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6671 bytes
Desc: not available
Url : http://lists.openswan.org/pipermail/dev/attachments/20081120/ae824001/attachment.bin 
-------------- next part --------------
---------------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: One Spencer Dock, North Wall Quay, Dublin 1
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.