My 2 bits:
I've ported Ted T'so' PRNG code to a few other systems, so I'm familiar
with it. It should collect entropy from all the system interrupts, including
the network card and pentium TSC (high speed clock) jitter, as well as
the data in some of the kernel buffers. So entropy should collect.
This is a PRNG, but it tries to keep an estimate of how much true entropy
it has gathered. This is actually impossible to know, it just guesses,
and when you try to extract more entropy than it estimates there is from
/dev/random, it blocks. Besides this, the output is from the same pseudo-
random number generator that /dev/urandom gives you output from. This
estimation is the diciest part of the whole thing. It is IMPOSSIBLE
to statistically estimate randomness.
Breaking the PRNG means from the output, guessing something about the
state of the pool. Knowing the state of the pool, you could then guess
future output. Most PRNGs use a secure hash function (SHA1 in the linux
case), so breaking the PRNG is equivalent to breaking SHA1. This is
hard.
I think that if you allow your linux box to gather a few hundred bits
of entropy, which is not hard, that breaking the PRNG will be equivalent
to breaking SHA-1 (160 bits), and probably as strong as the encryption
algorithm you are generating keys for. In other words, urandom should
be fine.
Looked at another way, what is egd going to gather? The input to your headless
box is the network card, and timers. The O/S acts as a filter for this
information to create process activity. This can't possibly create more
entropy, so what is egd possibly going to gather that the random device can't?
That's my 2 bits. The other point of view is that all PRNGs are worthless,
and anything less than h/w generated true random numbers is fooling yourself.
Cheers,
Sam
Quoting John Riganati <[EMAIL PROTECTED]>, who wrote:
> I am working with RedHat 7.1 with a 2.4.2 kernel, and I have run into a
> problem with saslpasswd. When using saslpasswd to set a user's password (or
> create a new user), it hangs indefinietly. Checking logs, I found that it
> was hanging while trying to set the PLAIN password. Digging through some
> archives, I found references to problems with /dev/random, and tried the
> following;
>
> % cat /dev/random
>
> Sure enough, /dev/random is blocked. From what I have gathered from yet
> more archives, /dev/random is seeded by the kernel with random input from
> things like the keyboard and the mouse, and when the entropy pool runs too
> low, the device blocks as a security precaution. Fair enough. The problem
> is, this machine is in a data center, so it has no keyboard and no mouse, so
> I believe it is not getting enough random input to keep the entropy pool
> sufficiently seeded.
>
> I have "fixed" the problem by linking /dev/random to /dev/urandom, but I
> know this is not a reasonable long term fix (not that good in the short
> term, either). Has anyone come across a reasonable way to keep /dev/random
> seeded on a machine with no keyboard or mouse, or with a good alternative to
> /dev/random?
>
> Thanks for the help - John
>
> [EMAIL PROTECTED]
>
>
--
Sam Roberts <[EMAIL PROTECTED]> (Vivez sans temps mort!)
