Wow. You really are not reading the same code, are you.
> [Just been following the discussions on the web archives, so sorry that
> I'm replying out of the email thread]
>
> * MD5 is used all the time in PRNGS. The collisions demonstrated aren't
> an issue if the attacker has almost no control over the input.
>
> * An unauthenticated attacker may be able to sample an almost arbitrary
> amount of output from your PRNG by making new IPsec connections.
Really? Prove it.
> As I
> understand it, each now sends 128 bits or so of output as plaintext over
> the wire in the IV. :-)
Four days ago, if you were using a particular set of hardware drivers,
then yes. But the software ipsec stack was fixed for this NINE YEARS
AGO.
What you just said was utterly careless.
> * How much of nanotime() is truly unpredictable to an attacker sitting
> directly on your local network cable? Maybe the bottom 10 bits, at best?
No. The upper bits are 'more known'. The lower bits are 'less known'.
How did you come to your conclusion?
> * I don't know OpenBSD's does it this way, but if you seed your entropy
> pool a incrementally few bits at a time, an attacker who learns the
> internal state one time will be able to keep following it if he can see
> some output regularly. The strength of the encryption algorithm used to
> stir it doesn't matter in this attack. The solution requires at least
> one pool that's re-seeded "catastrophically", i.e. by merging in
> hundreds of bits at once. The defender has considerable leverage to gain
> an advantage by making the computations more expensive.
Except we don't do what you suggest at all.
> * Unless you persist entropy across reboots, you are starting from a
> known state at boot.
We don't save entropy over boots. You are speaking of one specific way
of solving this, and we don't do that. You can read the code in /etc/rc
and /etc/rc.shutdown.
At shutdown, we save a block of OUTPUT from the PRNG.
At boot, right after some extremely early system setup, we load that
block in as ENTROPY.
Let me be exact: We do not save 'raw entropy'.
> * One reason you would want to XOR entropy into the pool is so that any
> nonrandom bits don't obliterate any randomness that they land on top of
> (assuming they're independent). Better still, use something like a hash
^^^^^^^^^^^^^^^^^^^^^^^^^
> function (or the compression function from one).
Moments later, a hash function is indeed used. It is called MD5.
> * If you have to drop KB of output from RC4, you might be better off
> with a hash function for stirring. Designers use hash functions because
> their one-wayness is a critical property. RC4 wasn't designed to be a
> one-way function any more than MD5 was designed to be used in CTR mode
> as a stream cipher.
You don't know
> * Here's a good summary of attacks:
> http://www.schneier.com/paper-prngs.pdf
Yes, a wonderful paper about designing a PRNG for ONE consumer.
If you had 1000 consumers of PRNG data, would you design a PRNG that way?
That is the question which I think OpenBSD asked and proceeded to solve.
> * People love to design and discuss RNGs. I don't know why.
>
> * This is a thoroughly researched area of crypto. Perhaps you might
> consider using a standard design? (If for no other reason than to save
> endless discussions?)
I disagree strongly. The field of research is a total disaster because
everyone tries to use ONE PRNG PER PURPOSE.
We don't do that. We data-slice one PRNG with ALL CONSUMERS.
Everyone else is using standard designs, and as a result they do not
provide enough output data, and therefore, they make decisions that
consider PRNG output EXPENSIVE, and then use it less.
My desktop machine is generating and consuming PRNG in many many
layers of the kernel PER PACKET, heck, per keystroke, while other
operating systems continue to use sequential IP id's.
Please go study what we have done before talking about it.
