On Wed, Dec 22, 2004 at 07:43:13PM +0100, Florian Weimer wrote: > * 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.
That's basically what /dev/urandom does, no? (Except that it has the undesirable side-effect of depleting the entropy estimate maintained inside the kernel.) > > 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.) On my PIII/666 running 2.4.26, I get 1.4 MB/sec from /dev/urandom. Seems plenty fast enough to me. (Fast, of course, being orthogonal to secure.) > 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. I'm baffled by the post you reference: Andrew Suffield writes on Mon, 20 Dec 2004 06:11:08 - > The security of the session is limited by the randomness of the > weakest key used. If you're going to use /dev/urandom then you might > as well just not encrypt the session at all. It wouldn't be massively > less secure, and it would be quite a lot faster. I *think* what that says is "generating a session key based on entropy from /dev/urandom is security-equivalent to no encryption at all". Which is so obviously false that I can't imagine that I'm not misreading. I will grant that *if* an attacker can reconstruct the state of the entropy pool (which in theory is possible if the attacker can gather N bits of information about the outputs, but would require a significant advance over the state of the art in cryptanalysis of the hash function, and probably about 2^N work) then a key generated from it is insecure. But the difficulty of extracting that much information about the entropy pool is enormous, and the challenge of reconstructing the state, given that information, is ... large. It would be less work to build a SQUID [1] and snoop the operation of your ALU from the white van parked across the street from the data center. So, I agree with you - while it would be preferable to generate session keys using the most conservative entropy estimates, it's a perfectly reasonable engineering compromise to use /dev/urandom. I'd rather have Good Enough encryption, universally deployed, than fall for the Purity of Essence^H^H^H^H^H^H^HRandomness whackos' claims that "Everyone must plug a Geiger counter into their serial port or We're All Going To Die". BTW, the Linux kernel guys are actively working on improving the security of /dev/*random and could benefit from experienced cryptographers willing to review work and make suggestions. Check out the linux-kernel archives for the past few months for subjects mentioning /dev/urandom and /dev/random. [1] Superconducting QUantum Interference Device, the Gibsonian gizmo used by the dolphin in _Johnny Mnemonic_ to extract "80 *Gigabytes*!" of information from the courier's brain-mounted memory module. -andy --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]