Re: [PATCH] API for true Random Number Generators to add entropy(2.6.11)

[Evgeniy Polyakov]

On Thu, 2005-03-24 at 15:56 -0500, Jeff Garzik wrote:

> > 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.
> 
> See the earlier discussion, when data validation was -removed- from the 
> original Intel RNG driver, and moved to userspace.
> 

I'm not arguing against userspace validation, but if data produced
_is_ cryptographically strong, why revalidate it again?

I definitely prefer such mechanism to be implemented, and if you want,
it
can be turned by default off, and can be turned on using new ioctl() 
over /dev/random.

> > 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.
> 
> No changes are needed, as the system is currently functional without 
> these changes.

And how HIFN driver can contribute entropy?
It needs to create /dev/hifn_random, and rngd should be patched too?
And even using any existing crypto framework why add 2 kernel/user
copying, if we _want_ fast RNG and _know_ that it is valid?

You may say, that hardware can be broken and thus produces 
wrong data, but if user want, it can turn it on or off.

What about new ioctl() that will enable/disable entropy contribution
from kernelspace without validating it? I can create a patch on
top of David's.

> 	Jeff
> 
-- 
        Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

Attachment: signature.asc
Description: This is a digitally signed message part