Re: [RFC] frandom - fast random generator module
From: Eli Billauer
Date: Thu Oct 16 2003 - 18:03:47 EST
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/