1995-09-18 - Re: Netscape’s random numbers

Header Data

From: hallam@w3.org
To: cypherpunks@toad.com
Message Hash: c3ae12394e8f326787cd8d3208adb68b9feb3e8f10712cc316df59ada917f399
Message ID: <9509181958.AA11906@zorch.w3.org>
Reply To: <v01510100ac836b357d90@[206.1.161.4]>
UTC Datetime: 1995-09-18 19:59:21 UTC
Raw Date: Mon, 18 Sep 95 12:59:21 PDT

Raw message

From: hallam@w3.org
Date: Mon, 18 Sep 95 12:59:21 PDT
To: cypherpunks@toad.com
Subject: Re: Netscape's random numbers
In-Reply-To: <v01510100ac836b357d90@[206.1.161.4]>
Message-ID: <9509181958.AA11906@zorch.w3.org>
MIME-Version: 1.0
Content-Type: text/plain



>Before we go to the news, perhaps we should demonstrate the exploitation of
>this hole. It would certainly make selling this story a whole lot easier.

In the first place it is a bit late for that. The problem is all over the net 
already. Expect press coverage tommorow or Wednesday. Secondly I would prefer a 
solution.


Random number generation and maintenance is a whole lot harder than RFC 1750 
makes out. Although that RFC has some usefull ideas it does not provide a 
blueprint fora secure ergodicity management facility.

When I wrote code for Shen I was very carefull in the use I made of the output 
of the ergodicity manager. In particular correlation is a major concern. If a 
pseudo random output is exposed it must not predjudice other random values.

Consider the class of attacks where Mallet receives a message from Alice and 
uses the knowledge of his random number to discover the random number used in 
Alice's later message to Bob.

I always use hash functions as a "one way trap" to ensure that values cannot be 
reverse engineered to discover the internal state of the random number 
generator. I am also careful to erase all internal state before exiting the 
program. 


	Phill Hallam-Baker





Thread