NEW Netscape RNG hole

[RingZero]

Phil argues this file handle being lost isn't a big mistake.
He describes how the function is actually called, which
does indeed show that it shouldn't be much of a problem.
However, Netscape had not revealed enough information about
their RNG to allow myself or other reviewers to determine how
critical it was. If, for example, this seeding function were
called once every time a secure connection were established,
losing a handle would be a major problem.

This seems like a good reason to ask for the code for
SEC_RandomUpdate(). You show us from what sources you gather bits,
but you don't show us how you mix them or, for that matter,
stream out "random" bits.

If you did have a description in your original published code
that was better than "mixing is accomplished with MD5", I
must've missed it.


RingZero

===========
From: Phil Karlton  <karlton at netscape.com>
Subject: Re: NEW Netscape RNG hole
Date: Sunday, October 08, 1995 1:39AM

RingZero wrote:
>
> Did anyone else notice a bug in the new, public Netscape
> RNG code? It appears that on Windows builds, during the
> RNG seeding, the function that hashes in file contents
> (EnumSystemFiles) doesn't close a file handle (lFileHandle).

I think you mean lFindHandle. I'm not a windows programmer, so I have
no idea if the enumerator needs to be cleaned up, but I will forward
your message to the appropriate folks here.

[...]

--****ATTENTION****--****ATTENTION****--****ATTENTION****--***ATTENTION***
Your e-mail reply to this message WILL be *automatically* ANONYMIZED.
Please, report inappropriate use to                abuse at anon.penet.fi
For information (incl. non-anon reply) write to    help at anon.penet.fi
If you have any problems, address them to          admin at anon.penet.fi