>Am I missing something here? The point is to get a _truly_ random number,
>right?
>
[ many good ideas snipped ]
Most of these items are, in themselves, known to fall between certain
ranges at most points in time. However, taking ALL of these things and
hashing them with SHA gives you a decent seed. This is a common enough
technique: look for all reasonable sources of entropy from your computer
system and glom them together. I like using a hash algorithm because it
means I don't have to know which bits contain the most entropy - I just
hash everything.
This is what I've done for our MacOS port of OpenSSL. Now, nothing is
perfect. But this gives you an excellent seed and rapid number generation.
Anyway, its a lot better than just using srand(time(NULL)), which I think
everyone here agrees is less than minimal for cryptographic purposes.
First I hash together:
1. All of the system "Gestalts". These are indicators of what
system components are installed, OS version number, and other discoverable
bits of info accessible through the Gestalt() function. There's several
dozen of these. When a particular feature isn't available, I add the
returned error code to the hash.
2. The entire contents of the process table, including app name,
pid, processor useage, etc.. Sort of like doing:
md5 < ps -ax
3. time, both from time() and the MacOS microseconds() call
4. open file queue, event queues, and other system queues (one of
the very few advantages of NOT having *nix-like kernel)
5. some other MacOS junk like mouse position and some screen bits
6. contents of the "lag seed" file, if available.
Next, this 128-bit hash is used to initialize a lag number generator. It
is rehashed until the table is full. I use about 4k in my lag generator.
If you don't know what a lag generator is, I refer you to Knuth's "Art of
Computer Programming" vol 2 "Seminumerical Algorithms". A lag generator
has the advantages of being very fast (requiring only addition to produce
"random" numbers) and having a very long period.
When a sequence of random bytes is asked for, I first generate and throw
away a prime number of bytes (19 I believe) then generate the requested
number of bytes. This lengthens the period of the lag generator even more.
Finally, every hour or so I dump a few k of random numbers into a "lag
seed" file. The next time the random number generator is used, it will add
these to the initial hash. Since the contents of this seed is dependent
not only on the previous sytem information but also the precise pattern of
useage of the PRNG, it is highly unpredictable.
This general technique is quite sound. Some people might want to add
(short of a special-purpose entropy generator) periodic sampling of
mouse/kbd/disk/screen activity. The main security consideration is that
you want to keep the "lag seed" file secure, as its disclosure will reduce
the value of your seed.
cjh
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
CJ Holmes "The Macintosh uses an experimental
StarNine pointing device called a 'mouse.'
Director of Development There is no evidence that people
want to use these things."
(John C. Dvorak, SF Examiner, Feb. 1984.)
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
