1995-09-21 - Random Number State

Header Data

From: Eric Young <eay@mincom.oz.au>
To: cypherpunks@toad.com
Message Hash: 92690c1496b80b0205f20b199644df066861a9d0b128df36b7b6b73a55c48151
Message ID: <Pine.SOL.3.91.950921113535.21127D-100000@orb>
Reply To: <9509202150.AA08164@toad.com>
UTC Datetime: 1995-09-21 03:38:49 UTC
Raw Date: Wed, 20 Sep 95 20:38:49 PDT

Raw message

From: Eric Young <eay@mincom.oz.au>
Date: Wed, 20 Sep 95 20:38:49 PDT
To: cypherpunks@toad.com
Subject: Random Number State
In-Reply-To: <9509202150.AA08164@toad.com>
Message-ID: <Pine.SOL.3.91.950921113535.21127D-100000@orb>
MIME-Version: 1.0
Content-Type: text/plain



Some some ramblings on the RNG seeding issue, comments welcome.

I'm sort of in the position of Netscape in that I have an SSL library 
that needs good random numbers for both RSA key generation (soon DH)
and SSL sessions.
While most of the discussions have been how to generate random data, one 
solution I will probably follow is that when any 'semi-random' data is 
generated, make sure to save this for seed data the next time the
application starts.  I have faith in the RNG capabilites of my RNG (based 
on MD5) and my RAND_seed() routine only 'adds' to the RNG state (about 
1k's worth is kept).  I can continue to 'mix' the RNG state at any point in 
time.  My RND_seed() xors into the existing state, it does not overwrite.

Because my SSL/encryption library contains 'everything', I have the
ability to put calls to my RNG_seed() routine in places like when I 
decrypt a private key.  I can pass both the password (if the key was 
encrypted) and the private key 
into the RNG state (making sure any data that goes into the RNG state 
can not be determinied if a 'core' file is generated).
I will probably also put the time() into the RNG state whenever an 
SSL_connect or SSL_accept is made (I think I do already).  I may also put in 
select data that has been read from the remote host
While most of this data can be determined by watching 
network activity, if it is just a delta to the initial random 
state it is somewhat more useful.

The first time use 'x' runs the application they are made to 'generate' 
some reasonable random data.  For all subsequent executions of the 
program, any more semi (psuedo?) random data generated can be mixed in 
with the initial random data.  The profile of the usage of the 
application would end up determining the random data to use.

I feel it is a bit much to try to generate good random data every time 
an application is run.

I believe this is the type of aproach PGP uses (I have not looked at the 
code).

eric
PS  I also do some 'evil' things in that I load 'garbage' bytes from the 
    stack into my RNG state whenever the RNG is called.  It may not be 
    random, but I bet it is hard to determine from the outside the 
    running program :-)  It can only help :-).
--
Eric Young                  | Signature removed since it was generating
AARNet: eay@mincom.oz.au    | more followups than the message contents :-)






Thread