Date: Thu, 22 Jun 2000 12:40:42 -0400
From: Bill Rebey <[EMAIL PROTECTED]>
In fact, to test this theory, I changed all of these to just "Sleep(1)" (no
random sleep time) to remove the RTL randomizer from the equation
altogether, and the results from consecutive trials are very different and
appear just as random and unpredictable.
Just because it -looks- fairly random is no guarantee you've got
anything like enough entropy there. Knuth's books have some info on
testing RNG's, but not on cryptographic ones; Schneier's books are a
better bet.
Here's a test you can do. I dunno how much precision you have for
measuring a time delay. Let's assume it's a microsecond. Let's
further assume that your Sleep(1) example never takes more than 2
seconds to finish. Already, we can see that you cannot possibly have
more than 2 million possible sleep delays, which is only about 21 bits
of entropy---and an exhaustive attack with a workfactor of 2^21 is
basically "one slow workstation for a few seconds". But in fact, it's
quite unlikely that the dispersion is so wide. [If the real app does
system calls instead of sleeps, time those instead. Etc.]
So create an array with two million elements, initialize them all to
zero, and call your Sleep(1) example a zillion times. Each time,
measure the time to return, and increment the appropriate array
element. You've just made a histogram of the distribution.
Examine it. It probably won't be a uniform Gaussian around 1 second,
so it's probably even less random than you think. Do an FFT on the
data and you'll probably find some distinct frequencies in the data.
These are probably related to periodic interrupts, aliasing and beat
frequencies between the CPU clock and the timer-interrupt clock, etc.
Any attacker will no doubt do the same thing, assuming that this is
the weakest point in your algorithm. (If there's a weaker point, a
smart attacker will look there, but it already sounds like your RNG
is going to be a weak point...)
And if this work is for healthcare.com, and thus (I assume) you're
handling patient data or other information that people considering
confidential, you really owe it to yourself and your patients to do
this right. This implies finding someone who -really- knows what
they're doing and having them find proven, peer-reviewed approaches
and implementations. Good crypto is no place for amateurs, and even
the pros require peer review to catch mistakes---no one is perfect.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
