Thanks for pointing this out. Like I said, I knew the array would probably
contain 64 instances of the same values, but I didn't know it was so
terrible, largely because I don't even understand what the big pool of data
is really used for.
You seem to have some legitimate insight into the random number generator.
I know this isn't a classroom session, but could you spare a few minutes to
tell me why we use these large pools of data to seed the RNG? I'm just
mimicking the behavior of example code that I find in various places, as
there seems to be no documentation about how any of this is supposed to work
or how the seed is used, etc.
Is it any better to use 64 longs to seed the RND than it is to use 1 or 5
longs?
Even if all 64 bytes in my seed array are the same, (say for instance
0x03F567A2) isn't
0x03F567A203F567A203F567A203F567A203F567A203F567A2.....(out to 256 bytes) a
sufficiently large and sufficiently "random value " with which to seed the
RNG? How could someone predict that?
Thanks for your time and advice,
Bill Rebey
-----Original Message-----
From: Goetz Babin-Ebell [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 20, 2000 1:30 PM
To: [EMAIL PROTECTED]
Subject: Re: Cipher question...
Bill Rebey wrote:
... an broken snake oil random generator.
> Start by running something like this before you do other SSL stuff:
> time_t seed[64];
> for (int ii = 0; ii < 64; ii++)
> {
> time_t t = time (NULL);
> seed[ii] = t;
> }
> RAND_seed (seed, 64 * sizeof (time_t));
>
> You'll might get 64 quantities all the same in the see array because the
> routine will complete in less time than the granularity of the 'time'
> function can measure, but it's still a random pile of bits and it
completes
> very quickly.
Since the granularity of time() is a second, you will get at most 2
different values.
you put in the random pool 64 * sizeof(time_t) (4) = 256 byte
But the randomnes is at most 2 bit.
your generated data will be terrible weak.
Something like times() or clock() would be better.
But you should store only the last 1 - 4 bits of every call in the
random pool...
It would be weak random data, but better than that you did (but that is
easy...)
> Some out there may hate this because it's not "random enough", but
solutions
It is not not "random enougt", it is no random at all...
By
Goetz
--
Goetz Babin-Ebell, TC TrustCenter GmbH, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
