Any kind of analysis of “how good is OpenSSL's RNG” would have to reject any contribution from the uninitialized data, because they have no way to guarantee that it's not predictable. Indeed, it is quite likely to be all 0 in many cases.
And indeed, the source code attributes no entropy to the uninitialized data. So there is some recognition of this fact in there already.
The messages from valgrind (and purify and whatever) are not harmless, on the other hand. False positives make it harder to debug programs that use OpenSSL; if things are harder to debug, more bugs survive; if more bugs survive, more security holes survive.
I agree entirely, which makes question even more why they've kept it in their despite it apparently being reported as a bug so often.
You're right about 'harmless' uninitialised reads obscuring real problems, C++ copy constructors are particularly bad for generating these when the original constructor doesn't initialise everything.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
(no subject)
Date: 2008-05-14 11:51 am (UTC)Any kind of analysis of “how good is OpenSSL's RNG” would have to reject any contribution from the uninitialized data, because they have no way to guarantee that it's not predictable. Indeed, it is quite likely to be all 0 in many cases.
And indeed, the source code attributes no entropy to the uninitialized data. So there is some recognition of this fact in there already.
The messages from valgrind (and purify and whatever) are not harmless, on the other hand. False positives make it harder to debug programs that use OpenSSL; if things are harder to debug, more bugs survive; if more bugs survive, more security holes survive.
(no subject)
Date: 2008-05-14 12:07 pm (UTC)You're right about 'harmless' uninitialised reads obscuring real problems, C++ copy constructors are particularly bad for generating these when the original constructor doesn't initialise everything.