On Thu, May 15, 2008 at 7:53 PM, Theodore Tso <[EMAIL PROTECTED]> wrote:
> On Thu, May 15, 2008 at 11:09:46AM -0500, John Parker wrote:
>> What I was hoping for was a -DNO_UNINIT_DATA that wouldn't be the
>> default, but wouldn't reduce the keyspace either.
>
> -DPURIFY *does* do what you want. It doesn't reduce the keyspace.
>
> The problem was that what Debian did went far beyond -DPURIFY. The
> Debian developer in question disabled one call that used uninitialized
> memory, but then later on, removed another similar call that looked
> the same, but in fact *was* using initialized data --- said
> initialized data being real randomness critically necessary for
> security.
This similar call would, under certain conditions, use uninitialized
data too. I guess Valgrind is more thorough than Purify, because it
seems that those using Purify were not shown this as suspicious, and
thus -DPURIFY didn't cover this particular case. Of course, totally
disabling the offending call in md_rand.c as was done in Debian was
blatantly wrong. The correct way would have been to change
RAND_load_file() in randfile.c; that's the function thatt might
sometimes pass uninitialized data to RAND_add() (intentionally, but
without relying on this uninitialized data as a source of randomness).
One of the offending RAND_add() calls has already been taken care of
about a year ago:
http://cvs.openssl.org/filediff?f=openssl/crypto/rand/randfile.c&v1=1.47.2.1&v2=1.47.2.2
However, another intentional use of potentially unitialized data is
still left as of
http://cvs.openssl.org/getfile/openssl/crypto/rand/randfile.c?v=1.47.2.2
:
i=fread(buf,1,n,in);
if (i <= 0) break;
/* even if n != i, use the full array */
RAND_add(buf,n,(double)i);
Changing this into RAND_add(buf,i,(double)i) should make verification
tools happier. Or it could be
#ifdef PURIFY
RAND_add(buf,i,(double)i);
#else
RAND_add(buf,n,(double)i);
#endif
(abusing the "PURIFY" macro with a more general meaning).
Bodo
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
