> 2010/12/21 Otto Moerbeek <o...@drijf.net>: > > Yes, predictable, but different for each call. > > hm... predictable is not a good term in the domain of a PRNG. > > However the time value will not be used by itself. It is part of an > encrypt operation with itself + buf and a previous RC4 state, at least > after the second call to arc4_stir. > > So, maybe this has no meaning at all. However I would "recommend" to > check this very thoroughly before changing any line of that code. > Maybe you'll add a weakness by removing the time value. > > I would recommend to do the follwoing, and I'm trying to do it myself > during the next few days. > > 1.) Rewrite arc4random() and arc4random_buf() to "store" all random > values from boot time until the establishment of a few IPSEC tunnels. > > 2.) Repeat that procedure a few times, i.e. reboot, ipsec, store, > reboot, ipsec, store, etc. > > 3.) Take all those pseudo random value sequences and feed them into > the NIST test suite for random values (chi-square, diehard, etc.) > > 4.) Repeat those steps after the removal of the time value from the code. > > 5.) Try to interpret the outcome of the NIST tests. Maybe other people > (real cryptographers) should help with this last step.
HANG ON. Go look at the function random_seed() in /usr/src/etc/rc Then look at when it is called. You are reading the code attempts to make-do in a world without any real entropy (minus a few interrupts) very very early in the boot process. Except in the case of nfs diskless, no network traffic has moved at that time, since no interfaces are up. Please keep that context in mind.
