[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. As I 
understand it, each now sends 128 bits or so of output as plaintext over 
the wire in the IV. :-)

* How much of nanotime() is truly unpredictable to an attacker sitting 
directly on your local network cable? Maybe the bottom 10 bits, at best?

* 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.

* Unless you persist entropy across reboots, you are starting from a 
known state at boot.

* 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).

* 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.

* Here's a good summary of attacks:
http://www.schneier.com/paper-prngs.pdf

* 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?)

- Marsh