Re: [RFC] frandom - fast random generator module

[Eli Billauer <eli_billauer@users.sf.net>]

Matt Mackall wrote:

>On Thu, Oct 16, 2003 at 07:29:05AM -0400, Jeff Garzik wrote:
>  
>
>>So, given that trend and also given the existing /dev/[u]random, I 
>>disagree completely:  /dev/frandom is the perfect example of something 
>>that should _not_ be in the kernel.  If you want /dev/urandom faster, 
>>then solve _that_ problem.  Don't try to solve a /dev/urandom problem by 
>>creating something totally new.
>>    
>>
>
>I have some performance fixes for /dev/urandom, but there's a fair
>amount of other cleanup that has to go in first.
>
... and this reminded me that I originally wanted to patch random.c, and 
change the algorithm to the faster one. To my best understanding, there 
would be no degradation in random quality, assuming I would do it 
correctly (and not being hung for the nerve to do it). But that's the 
problem: What if I got something wrong?

If a hardware device driver is buggy, you usually know about it sooner 
or later. If an RNG has a rare bug, or an architecture-dependent flaw, 
it's much harder to notice. If the RNG starts to repeat itself, you 
won't know about it, unless you happened to test exactly that data. The 
algorithm may be perfect, but a silly bug can blow it all.

So personally, I wouldn't touch the urandom code, not even the smallest 
fix. Instead, I decided to write another RNG, which doesn't interfere 
with the existing one. The only way to be confident about it, is to give 
it mileage. And that means making it available for broad use.

Which is why I originally offered frandom as a supplement, not an 
alternative.

   Eli