On Fri, Jun 23, 2000 at 12:41:14PM -0400, Bill Rebey wrote:
> 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
> 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?"
We should distinguish several groups of people:
- some people run Linux or *BSD, where mechanisms to collect entropy are
part of the kernel. There are interrupts, especially when human interaction
is utilized, that can give you easily a good amount of entropy.
- Most other people have the problem to find a good seed for the PRNG,
but they don't know, since the software author applied a snake oil
seeding and probably they never learn about the problem or they learn
the hard way.
- Other people (like you and me) are affected by having the problem and
the knowledge, that we have it :-)
Having this said, to find a suitable solution depends on a risk analysis.
Consider a safe place to save the seed, e.g. on hard disk. Then you can
generate a good seed from a good source (hardware or EGD on your server or...)
for each client. This seed is used at startup and then over time more entropy
is added and the seed is restored to disk on exit.
Since the seed is stirred around all the time and more entropy is added,
I would say, that this scheme should be quite good. Of course, you should
generate a different initial seed for each client.
This scheme is ok as long as you are working against external eavedroppers.
If you have an in-house problem with somebody who could "steal" the seed-file,
it is not safe. If somebody can access all of your data on hard disk, he
might however decide to mess with your software or keys or certificates,
that is probably easier than trying to analyze your PRNG seed...
As I already said, you have to analyze your threat.
> 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?).
The OpenSSL PRNG has 8192 state bits, so if there is no design error,
it should not be possible to guess the PRNG state from the random
number generated. Consider you obtain 168bits for a 3DES connection,
then even if you could get information about the internal state of the
PRNG (and you should not), you would still have to guess 8192-168 bits.
So this is really safe enough.
The internal state is changed, whenever random numbers are generated,
so whenever you write back to the seed file, you have a new state to
start with.
Now, if you add a small amount of entropy over time, you can even improve
the situation. Consider a program that runs 24h per day and can generate
a single bit of entropy per minute, that will give you another 1440 bits
per day. As we have already seen in the PRNG discussion, timers, process
ids etc will not give you much entropy, but 1 bit per minute should not
be too hard to get. This is of course just an example for a calculation,
but with a 168bit 3DES encryption being considered unbreakable as of today,
an additional entropy of 1440 bits per day is really generous.
> 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?
Again, the amount of data is not important, it is the amount of uncertainty.
Consider a call of the gettimeofday() function. It will give you some amount
of data, but if I know when the function was called, I can tell you most
of the bits. If your clock is not precise and I only know part of the
necessary information (your program first calls gettimeofday(), then waits
for some (random) amount of time before opening the connection, an eavesdropper
can only guess the time-data used for seeding up to a limited precision).
The information he does not have, is what you are really looking for.
Anyway, the symmetric key (128bits for RC4-MD5 or 168bits for 3DES in the
non-export versions that should be considered standard today) are the
minimum amount of random bits you need. The OpenSSL PRNG requires 16bytes
(128bits), if memory serves me right...
Disclaimer:
I personally use cryptographic methods for password protection and to
protect against curious people in our old unprotected 10base2 ethernet
subnet. I have nothing really precious to protect, our research results
are published anyway ("publish or parish" or so) and besides our basic
FEM software (which I distribute to our research partners at other parts
of the world for cooperation projects), software I write tends to show
up as OpenSource :-) Your threat analysis might be far more serious...
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
