openssh unix dev - Sep 2000 - Performance hits from seeding the random number generator

What kind of connection delays are people seeing with Ossh 2.2.0p1??

One of the programmers here is seeing delays of up to 25s, which is clearly
unacceptable.  He's localized the problem to seeding the random number
generator - it appears that the _minimum_ number of commands needed to seed
the random number generator is 16.  On his hosts (for a variety of reasons),
many of those commands time out. We're reconfiguring OSSH to avoid the
commands that time out, but we've also considered alternate methods of
seeding the random number generator.

One of our other folks has written a function that produces random output
for another program.  It has been subjected to some informal statistical
analysis, and we're considering using it to see the random number generator,
rather than the current method - if it works, I'll see about releasing the
code.  Since it will be compiled code vice 16+ fork/exec calls, it should be
much faster.

However, I'd like to know if the current seed method has been subjected to
any formal analysis (if so, I'd like to submit out function to the same
analysis).  


Mark Wallace

Wallace, Mark, CTR, OSD/ATL wrote:
> One of our other folks has written a function that produces random output
> for another program.  It has been subjected to some informal statistical
> analysis ...
Statistical randomness is only one requirement for cryptographic
systems.  You also don't want output from the random number generator
to be predictable, given old data and the state of the system.  For
example, the typical C library rand() function passes statistical
tests up to a point, but is also completely predictable.

If your random function satisfies this then it could be worth using.
Otherwise using it would probably compromise your security.

-- 
Pete