Re: [RFC] frandom - fast random generator module

[davidsen@tmr.com (bill davidsen)]

In article <3F97498D.9050704@storm.ca>, Sandy Harris  <sandy@storm.ca> wrote:

| Do you think you need this before there's a file system? Why?
| Or are you thinking of boxes that don't have a file system?
| Or not writable? Not local?
| 
| > --and even speed),
| 
| I suspect that's the real issue. People report using other
| things because /dev/urandom is too slow.
| 
| Can we speed up /dev/urandom? Or perhaps write a PRNG daemon?

I know someone noted that frandom couldn't just replace urandom, but I
don't recall why. The values appear to be at least a good, the speed is
much higher, and since it's already in use, there would be no opposition
to having it, since we need to have something.

Could someone clarify why this isn't a drop-in replacement?

| If all we need is a library, there's an RC4-based one named
| prng.c in the FreeS/WAN libraries.
| http://www.freeswan.org/freeswan_snaps/CURRENT-SNAP/doc/manpage.d/ipsec_prng.3.html
| 
| Two threads discussing the desin start at:
| http://lists.freeswan.org/pipermail/design/2002-March/002166.html
| http://lists.freeswan.org/pipermail/design/2002-March/002207.html
| 
| > but the Kent who doesn't
| > want the kernel to be exploded into a catalogue of competing random
| > number generators.
| 
| I'm with you there.

No argument, but the performance of urandom is quite poor in terms of
speed and having every application generate their own number using
their own possibly badly flawed algorithm certainly qualifies as
undesirable.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.