Hello!
I know that a large PKI company uses their own homemade entropy
collector to initialize the seed for the keygeneration of their
smartcards. The entropy collector requires the admin to move around the
mouse for quite a while, so this might not be applicable in a case
requiring automation. (note that this is quite a pragmatic solution, and
as far as I know not based on anything else than intuition)
I too would be very interested if somebody knows why a certain "physical
random source" is considered random (any physics guys here? :-).
> This has all been incredibly helpful, and I've been trying to read up on
> this matter. I'm finding radioactive isotope counters, FM static samplers,
> thermal noise samplers, etc. Lots of cool hardware solutions. I need a
Could you post some references that you found interesting?
/douglas
> software solution, though, and they seem quite elusive. The obvious
> question that comes to mind, though, is:
>
> "What is everyone else doing to get random seed data? Why is it so hard for
> me?"
>
> All I want to do is automatically re-seed the PRNG on a daily basis (Is that
> even enough? Is it too much? Is it even statistically significant to change
> the random seed at all?).
>
> Am I missing something?
>
> Also, what is considered a "good" amount of seed data? I'm using 64 Bytes.
> Is that a lot? Is 64KB more appropriate? Something in the middle, perhaps?
>
> Thanks for all your help and patience, everyone, and for not throwing
> tomatoes at me in mockery.
>
> Bill Rebey
>
> -----Original Message-----
> From: Lenny Foner [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 22, 2000 1:09 PM
> To: Bill Rebey
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Cipher question...
>
> 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]
--
------------------------------------------------------
Douglas Wikström <[EMAIL PROTECTED]>
------------------------------------------------------
Yes, God created Man before Woman,
but one always makes a draft before the masterpiece.
------------------------------------------------------
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
