Daniel Kahn Gillmor <[EMAIL PROTECTED]> wrote: > I've packaged gnutls 2.3.4 (upstream's current development version) > for my own testing, and i see the same behavior described in this > ticket using 2.3.4 on a lenny/sid i386 system (see strace and package > versions below). So the problem isn't unique to the version in lenny. > > I'm afraid I don't know enough about crypto to know why reading from > /dev/urandom (a PRNG itself, aiui) would be cryptographically worse > than implementing your own internal PRNG and seeding it from > /dev/urandom, which seems to be what this bug is suggesting would be > better. I'd be happy to learn, though. > > By comparison, "openssl dhparam" only reads 32 bytes from /dev/urandom > for the same task (and uses its own PRNG according to dhparam(1ssl)). > > Regards, > > --dkg
Then let me try to enlighten you. Yes, /dev/urandom is itself a PRNG, so if your code doesn't include a PRNG, then you can just use its output directly. It is a bit wasteful of the entropy that the kernel driver keeps track of, and the kernel PRNG is particularly slow, but it's not too horrible. But if you have implemented a cryptographic PRNG for whatever reason, then there is no reason at all to use more seed material than reasonably necessary. Using stupid amounts of seed material is like putting huge spoilers on a rice-car: pointless and makes you look stupid. And annoys everyone who has to share the road (entropy pool) with you. In truth, even using 32 bytes is unnecessary in the case of generating a D-H prime, but that's a reasonable default for all cryptographic operations, and openssl didn't bother implementing a special case. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]