1995-10-16 - Re: NEW Netscape RNG hole

Header Data

From: Phil Karlton <karlton@netscape.com>
To: cypherpunks@toad.com
Message Hash: 4399f50e4cef8c94d62868d8e6522d50ce7a3a48cb3a3f9ef9791d94aaf3e3e9
Message ID: <30829B5D.41C6@netscape.com>
Reply To: N/A
UTC Datetime: 1995-10-16 17:50:04 UTC
Raw Date: Mon, 16 Oct 95 10:50:04 PDT

Raw message

From: Phil Karlton <karlton@netscape.com>
Date: Mon, 16 Oct 95 10:50:04 PDT
To: cypherpunks@toad.com
Subject: Re: NEW Netscape RNG hole
Message-ID: <30829B5D.41C6@netscape.com>
MIME-Version: 1.0
Content-Type: text/plain


[I sent this to the wrong address last week. A side effect seems to that
I now I have an anonymous ID.]

RingZero wrote:

> 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.

Yes. The README was not as explicit on this point as my original
message. SEC_SystemInfoForRNG is indeed among the global initialization
routines.

> This seems like a good reason to ask for the code for
> SEC_RandomUpdate().

As was stated in the README, I cannot publish that code. It's derived
from (and remarkably similar to) code that Netscape has licensed. It's
not ours to divulge.

> 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.

There seems to be little point in extracting isolated lines of
code out of the source to "prove" that we use the functions we
claim to use. If you have familiarity with RSAREF or the BSAFE
toolkit, you will be able to see how we mix and extract the
"random" bits.

PK
--
Philip L. Karlton			karlton@netscape.com
Principal Curmudgeon			http://www.netscape.com/people/karlton
Netscape Communications Corporation





Thread