Patch attached.

JLC

On Thu, Mar 31, 2005 at 08:58:22AM -0500, Jean-Luc Cooke wrote:
> On Thu, Mar 31, 2005 at 01:52:14PM +1000, David McCullough wrote:
> > 
> > Jivin Jeff Garzik lays it down ...
> > ...
> > > >If kernelspace can assist and driver _knows_ in advance that data
> > > >produced is cryptographically strong, why not allow it directly
> > > >access pools?
> > > 
> > > A kernel driver cannot know in advance that the data from a hardware RNG 
> > > is truly random, unless the data itself is 100% validated beforehand.
> > 
> > You can also say that it cannot know that data written to /dev/random
> > is truly random unless it is also validated ?
> > 
> > For argument you could just run "cat < /dev/hwrandom > /dev/random"
> > instead of using rngd.
> > 
> > If /dev/random demands a level of randomness,  shouldn't it enforce it ?
> > 
> > If the HW is using 2 random sources, a non-linear mixer and a FIPS140
> > post processor before handing you a random number it would be nice to
> > take advantage of that IMO.
> 
> 
> For those who are interested, my Fortuna patch to the Linux RNG (/dev/random,
> /dev/urandom) is available here (2.6.12-rc1, works on kernels as low as
> 2.6.11.4):
>   http://jlcooke.ca/random/
> 
> Fortuna is a Cryptographically Secure Random Number Generator (CSRNG)
> developed by Neils Ferguson and Bruce Schnier and published in their book
> Applied Cryptography.
> 
> By most regards, it is the state of the art as far as software based CSRNGs
> go.  The website gives an over view of the design, here is a summary:
>   Fortuna uses a block cipher (AES128) in CTR mode to generate output.
>   Fortuna uses a 32 hash states (SHA-256) which collect event data from
>   sources of randomness (as usual in Linux).
>   Once every 0.1sec or so, some of the hash states are finalised and the
>   digests are collected.
>   These digests are hashed together with with the current block cipher key to
>   produce the new block cipher key.
> 
> Ferguson goes into detail in Practical Cryptography as to why this design is
> superior to Yarrow based RNG (like the existing Linux RNG) and also delves
> into why entropy estimation is impossible and is infact a liability in RNG
> design.
> 
> My patch keep the entropy estimation from the current Linux RNG since this is
> a very controversial issue with most people.  Disabling entropy estimation
> and /dev/random blocking can be done by changing the RANDOM_NO_ENTROPY_COUNT
> macro to 1.
> 
> I have not tested the syncookie code yet.  But networking works smoothly
> after I echo "1" to /proc/sys/net/ipv4/tcp_syncookies.  Any help on this
> would be great.
> 
> JLC
> _______________________________________________
> 
> Subscription: http://lists.logix.cz/mailman/listinfo/cryptoapi
> List archive: http://lists.logix.cz/pipermail/cryptoapi