lkml.org 
[lkml]   [2005]   [Mar]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
From
Date
On Thu, 2005-03-24 at 23:23 +1000, David McCullough wrote:
> Jivin Jeff Garzik lays it down ...
> > Evgeniy Polyakov wrote:
> > >On Thu, 2005-03-24 at 14:27 +1000, David McCullough wrote:
> > >
> > >>Hi all,
> > >>
> > >>Here is a small patch for 2.6.11 that adds a routine:
> > >>
> > >> add_true_randomness(__u32 *buf, int nwords);
> > >>
> > >>so that true random number generator device drivers can add a entropy
> > >>to the system. Drivers that use this can be found in the latest release
> > >>of ocf-linux, an asynchronous crypto implementation for linux based on
> > >>the *BSD Cryptographic Framework.
> > >>
> > >> http://ocf-linux.sourceforge.net/
> > >>
> > >>Adding this can dramatically improve the performance of /dev/random on
> > >>small embedded systems which do not generate much entropy.
> > >
> > >
> > >People will not apply any kind of such changes.
> > >Both OCF and acrypto already handle all RNG cases - no need for any kind
> > >of userspace daemon or entropy (re)injection mechanism.
> > >Anyone who want to use HW randomness may use OCF/acrypto mechanism.
> > >For example here is patch to enable acrypto support for hw_random.c
> > >It is very simple and support only upto 4 bytes request, of course it
> > >is
> > >not interested for anyone, but it is only 2-minutes example:
> >
> > If you want to add entropy to the kernel entropy pool from hardware RNG,
> > you should use the userland daemon, which detects non-random (broken)
> > hardware and provides throttling, so that RNG data collection does not
> > consume 100% CPU.
> >
> > If you want to use the hardware RNG directly, it's simple: just open
> > /dev/hw_random.
> >
> > Hardware RNG should not go kernel->kernel without adding FIPS tests and
> > such.
>
> For reference, the RNG on the Safenet I am using this with is
> FIPS140 certified. I believe the HIFN part is also but I place the doc that
> says so.

At least HIFN 795x is certified.

Idea to validate entropy data is good in general,
but it should be implemented in a way allowing external both in-kernel
and userspace
processes to contribute data.
So for in-kernel use we need such a mechanism, and userspace gkernel
daemon
should use it(as the latest "step") too.

Your changes are correct, ioctl(RNDADDENTROPY) could even use it instead
of direct
add_entropy_words()/credit_entropy_store(), but without external entropy
contributors
it will not be applied by maintainers.

> Cheers,
> Davidm
>
--
Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2005-04-06 13:30    [W:0.078 / U:2.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site