[lkml]   [2005]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] API for TRNG (2.6.11) [Fortuna]
    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

    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

    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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-04-06 13:31    [W:0.021 / U:0.168 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site