[Openswan dev] Support for hardware random number generators
David_Mccullough at securecomputing.com
Thu Nov 20 06:26:12 EST 2008
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
dd if=/dev/random of=/dev/null
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.
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. Thsi would be a small patch, but as I said, it wouldn't
really gain you anything.
> >-----Original Message-----
> >From: David McCullough [mailto:David_Mccullough at securecomputing.com]
> >Sent: 20 November 2008 00:56
> >To: Paul Wouters
> >Cc: Vrabete, Brad; dev at openswan.org
> >Subject: Re: [Openswan dev] Support for hardware random number
> >Jivin Paul Wouters lays it down ...
> >> On Wed, 19 Nov 2008, Vrabete, Brad wrote:
> >> > That's exactly what I'm running now but I'm concerned
> >about performance:
> >> > rngd is running in the user space and all these user space
> >to kernel
> >> > (and
> >> > back) transfers are using processor time. I was trying to find a
> >> > way to use a proper HW RNG (no streams of 0, FIPS
> >compliant) without
> >> > having to use rngd.
> >> You'd have to move FIPS compliance into the kernel. And
> >Linus does not
> >> want policy into the kernel....
> >Fair call, OCF has a "pseudo fips" test on all RNG data it
> >pushes into the kernel.
> >It's not just Linus either, the general consensus from most
> >kernel people on the topic is that your HW RNG data should be
> >pushed to user space and back. So happens I don't agree,
> >especially on small embedded systems ;-)
> >> > I know OCF adds that but the OCF function does not get called on a
> >> > system with a HD, due to the way Linux's entropy pool is
> >filled (on
> >> > every disk access and/or interrupt). Any suggestions?
> >> Perhaps OCF could get a hook to do this? David?
> >I don't believe that is the case any more. Current OCF
> >versions put directly into the entropy pool from the HW and
> >keep the pool full.
> >Unfortunately you need kernel patches to do this.
> >> > Are you using get_random_bytes in Openswan?
> >> That is used at various places, yes. (KLIPS, not sure about
> >NETKEY, I
> >> don't think it does)
> >The OCF stuff fills the standard pools, so in kernel and
> >userspace will benefit,
> >David McCullough, david_mccullough at securecomputing.com,
> >Ph:+61 734352815
> >Secure Computing - SnapGear http://www.uCdot.org
> 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.
David McCullough, david_mccullough at securecomputing.com, Ph:+61 734352815
Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com
More information about the Dev