Team,

I have attempted to gather everyones comments into this re-write of my Fortuna
/dev/random patch.  I will summarize.

1.      Requires the Cryptographic API.

2.      Enable the Fortuna replacement to random.c in the Cryptographic Options menu
        of kernel config.

3.      As-is, it checks at compile time that AES and SHA256 are built-in modules.

4.      You can change this block cipher and message digest setting in the
        crypto/random-fortuna.c file.  /proc/sys/kernel/random/digest_algo
	and cipher_algo are now strings telling the users what algorithms are
	being used.

5.      Entropy estimation still exists in much the same way as in the Legacay
        random.c with the following exceptions:
  a.    /proc/sys/kernel/random/read_wakeup_thresholds lower limit was 8, it is now
        0 for those of us crazy enough to want to remove blocking.
  b.    /proc/sys/kernel/random/entropy_avail only increases when data is added to
        pool-0.  Pool-0 is the only 1 out of 32 Fortuna pools which is drawn from
        at every reseeding.  So we don't over-estimate the amount of entropy we
        consume, this change was done.
  c.    Since Fortuna resists consuming its entropy, it seemed inappropriate to debit
        1MB of entropy from the count when reading 1MB from /dev/urandom.  Now, every
        reseeding deducts min(cipherKeySize, hashDigestSize) from the entropy count.
        It should be noted that by doubling the blocksize from which you read
        /dev/urandom, you double the speed since you reduce the number of reseeds by
        a half.

6.      The input mixing and output generation functions now use Fortuna
  a.    32 independent feedback input mixing pools using a cryptographic hash from the
        CryptoAPI are feed event data in round robin.
  b.    A block cipher in CTR mode generates the output.
  c.    Every file system block read from /dev/{u}random causes Fortuna to reseed
  	the block cipher's key with the digest output from 1 or more of the input
	mixing pools.  Pool-0 is used every time, pool-j is used every 2^j times.
	
7.      Since Fortuna resists consuming its entropy, saving the 2048 byte random-seed
        should be changed to:  dd if=/dev/urandom of=$seedfile bs=256 count=8.  After
        2^3 = 8 block reads, pools 0, 1, 2, and 3 will certainly be used.  After
        2^4 = 16, pools up to number 4 will be used and so on.

8.      The difference in bzImage size is 7,268 bytes on my P4 laptop.  This is a
        compressed image.  My comparison was the 2.6.8.1 tarball with no kernel config
        changes vs. Enabling the cryptoapi, Fortuna, AES (i586 assembly) and SHA256.
	I have not yet done run-time memory consumption comparisons, but
	Fortuna is certainly heavier than Legacy.

9.      The difference in performance in /dev/random is roughly a 32x decrease in
        output rates due to the 32x decrease in entropy estimation (see 5.c)

10.     The difference in performance in /dev/urandom is 3x increase in output rates
        for a 512 byte block size.  A doubling in block size, doubles the performance.
        I produced 512,000,000 bytes of output with a 32k block size in less than 10
        seconds.  The legacy /dev/urandom by comparison accomplished the same thing in
        2.5 minutes.  The assembly version of AES for the i586 gets credit for this.

I tried to test the syn-cookie code but was unable to determine if it works.
Printk()s in the syn cookie generation function were never called even though I
echod 1 to the proc file.  If someone can tell me what Im going wrong, I'd love
to test this further.

I'd appreciate beta-testers on other platforms to provide feedback.

JLC