(Why hasn't anyone been cc:ing Matt on this?) On Dec 4, 2007 8:18 AM, Adrian Bunk <[EMAIL PROTECTED]> wrote: > On Tue, Dec 04, 2007 at 12:41:25PM +0100, Marc Haber wrote: > > > While debugging Exim4's GnuTLS interface, I recently found out that > > reading from /dev/urandom depletes entropy as much as reading from > > /dev/random would. This has somehow surprised me since I have always > > believed that /dev/urandom has lower quality entropy than /dev/random, > > but lots of it. > > man 4 random > > > This also means that I can "sabotage" applications reading from > > /dev/random just by continuously reading from /dev/urandom, even not > > meaning to do any harm. > > > > Before I file a bug on bugzilla, > >... > > The bug would be closed as invalid. > > No matter what you consider as being better, changing a 12 years old and > widely used userspace interface like /dev/urandom is simply not an > option.
You seem to be confused. He's not talking about changing any userspace interface, merely how the /dev/urandom data is generated. For Matt's benefit, part of the original posting: > Before I file a bug on bugzilla, can I ask why /dev/urandom wasn't > implemented as a PRNG which is periodically (say, every 1024 bytes or > even more) seeded from /dev/random? That way, /dev/random has a much > higher chance of holding enough entropy for applications that really > need "good" entropy. A PRNG is clearly unacceptable. But roughly restated, why not have /dev/urandom supply merely cryptographically strong random numbers, rather than a mix between the 'true' random of /dev/random down to the cryptographically strong stream it'll provide when /dev/random is tapped? In principle, this'd leave more entropy available for applications that really need it, especially on platforms that don't generate a lot of entropy in the first place (servers). Ray -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
