Just to follow up on Bodo's comment here; On Thursday 15 May 2008 11:11:50 Bodo Moeller wrote: > > Are we really relying on uninitialized memory for randomness? > > Not at all. It's just that OpenSSL in some situations tries to feed > possibly uninitialized memory into the random number generator anyway, > essentially just for fun and because their *might* be some actual > randomness there from whatever happened earlier in the same process.
As Bodo says, the worst-case is that this doesn't help but doesn't harm either. In the best case, buffers provided by the caller may contain some data we can mix into the PRNG. However, *if* (and I stress the conditional here) the caller buffers *do* happen to contain any entropy, that provides two potential benefits to openssl and the caller application; (1) callers are not just draining the PRNG one-directionally but are also helping to provide some entropy as well (NB, we don't score this entropy because it may be low-quality or even useless), (2) if the buffers passed from different points in the caller code vary at all (even if the entropy within each such buffer is low-quality or even 100% predictable) then the PRNG state becomes caller-pattern-dependent. Ie. if the pattern of calls to openssl's PRNG varies between runs, then the PRNG state is fundamentally altered between runs too. Each such buffer could always contain the same data on entry, but the *order* in which those buffers hits the PRNG could provide some entropy if, for example, threading is unpredictable. Ie. there is potentially entropy in the order of the calls, rather than in the buffers being passed in those calls. All of this is independent of proper entropy seeding to the PRNG, which is what the debian patch crushed and which in turn led to the high seismic reading in the blogosphere. But it may help explain why I do *not* want us to unilaterally remove the use of uninitialised data in the PRNG. That seems to be motivated by a capitulation to the weight of users (or packagers) who don't know how to read the FAQ. Perhaps what we should do instead is change -DPURIFY to -DNO_UNINIT_DATA or something else which has a clearer intention, so that debug packages (or even base packages that want to be valgrind-friendly) have a straightforward mechanism to apply. Well, a straightforward mechanism that doesn't kill the PRNG outright, I mean (otherwise there is already a highly-publicised patch we could apply...) Cheers, Geoff ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
