* Victor Duchovni: >> The Debian folks have recently stumbled upon a problem in this area: >> Generating the ephemeral DH parameters is expensive, in terms of CPU >> cycles, but especailly in PRNG entropy. The PRNG part means that it's >> not possible to use /dev/random on Linux, at least on servers. The >> CPU cycles spent on bignum operations aren't a real problem. >> >> Would you recommend to switch to /dev/urandom (which doesn't block if >> the entropy estimate for the in-kernel pool reaches 0), and stick to >> generating new DH parameters for each connection, or is it better to >> generate them once per day and use it for several connections? >> > > Actually reasoning along these lines is why Lutz Jaenicke implemented > PRNGD, it is strongly recommended (at least by me) that mail servers > use PRNGD or similar. PRNGD delivers psuedo-random numbers mixing in > real entropy periodically. > > EGD, /dev/random and /dev/urandom don't produce bits fast enough.
Is this the only criticism of /dev/urandom (on Linux, at least)? Even on ancient hardware (P54C at 200 MHz), I can suck about 150 kbps out of /dev/urandom, which is more than enough for our purposes. (It's not a web server, after all.) I'm slightly troubled by claims such as this one: <http://lists.debian.org/debian-devel/2004/12/msg01950.html> I know that Linux' /dev/random implementation has some problems (I believe that the entropy estimates for mouse movements are a bit unrealistic, somewhere around 2.4 kbps), but the claim that generating session keys from /dev/urandom is a complete no-no is rather surprising. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]