On Tue, May 20, 2008 at 12:09 AM, Bodo Moeller <[EMAIL PROTECTED]> wrote: > On Mon, May 19, 2008 at 11:57 PM, Richard Stoughton <[EMAIL PROTECTED]> wrote: > >> - do not mix the PID into the internal entropy pool, and > > The OpenSSL PRNG uses the PID twice: > > Once it is used as part of the intitial seeding on Unix machines, to > get some data that might provide a little actual entropy. This part > wasn't functional in the Debian version, because the content of each > and every seed byte was ignored. > > But then the PRNG also mixes the PID into the output (via a hash). > This is why the PID did influence the output bytes on Debian. The > point in using the PID here is *not* to collect entropy. Rather, it > is to ensure that after a fork() both processes will see different > random numbers. Without this feature, many typical Unix-style server > programs would be utterly broken.
I see. As far as I can understand the code, the suggested usage pattern for the RNG would be ssleay_rand_bytes(ssleay_rand_add ^ n) with n > 0. If consecutive calls to ssleay_rand_bytes without intermediate calls to ssleay_rand_add are allowed, your objection is obviously more than justified. >> - do not mix bits of the given output buffer into the internal entropy pool. > >> Note that the second improvement may totally break already broken >> client software. > > Why would it? Clients that do not call ssleay_rand_add at all would probably get a random series with even less variance than the debianized one has. However, I cannot see that the second point would make the correctly used RNG weaker. Would it? ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
