Holy cow, you are dense.

I am going to throw out estimates here because (a) it has been a long
time since we tested, and (b) so much can vary machine to machine.

Without a hardware RNG device, a typical i386 desktop machine can
provide (based on interrupt sources) around 1800 bytes of base entropy
to the MD5 thrasher -- per minute.

Meanwhile, OpenBSD is consuming about 80 KB of arc4random output per
minute.  How do you convert 1800 bytes of input to 81920 bytes of
output, while giving references out to papers that don't solve this
problem.

And how do you make it fast.  Because all those papers try to solve
the problem by making it SERIOUSLY SLOWER.

While all this is going on, each userland application is using random
data out of it's own libc arc4random for many purposes, including per
malloc() and free() amongst many others, and are re-seeding their libc
generators from the kernel as required, putting even more pressure on
the kernel.

You don't know what you are talking about, and you don't seem to have the
ability to wrap your mind around all the parts that are involved.

I am not reading your mails again.

[ message continues ]

Finally something concrete to discuss.

That ought to be enough for anybody once it gets going. Of course, 

Is that supposed to sound like a lot? I mean modern CSPRNGs generate 
hundreds of MB per second, per core.

What do you mean exactly by "OpenBSD is consuming"? Are you referring to 
the kernel or userland arc4random?

Probably you think these are ridiculous questions.
HMM PERHAPS I'LL GO LOOK AT THE SOURCE CODE AND FIND OUT FOR MYSELF.
Back.

I was wondering how this was supposed to work because other posters had 
implied that OpenBSD's "many consumers" of arc4random were (through some 
mechanism no one could explain) contributing so much entropy back into 
the system pool that this design was categorically better.

So if all 80KB per minute were being consumed by one instance of 
lib/libc/crypt/arc4random.c in one user process, it would 'stir' about 
once every 20 minutes, adding about two or three nanotimes' worth of 
uncertainty. But of course there are many user processes and if you 
meant this 80KB were divided among them and it probably happens less 
often than that.

The reseeding of the kernel arc4random is on a fixed 10 minute timeout. 
Since it's obviously broken to ask a kernel timeout to generate 
unpredictable bits from its own clock, the timeout just sets a flag so 
it stirs on the next request for data. Ironically, this has the effect 
of making the bits from nanotime more predictable the more often that 
data is queried from the kernel.

So the "many consumers" of random data are not feeding back significant 
entropy by making unpredictable requests. Probably the main contribution 
from the typical consumer is the one-time seeding after fork.

The other way in which the "many consumers" theory is said to be 
justified is the idea that these consumers are reading varying-sized 
segments from the kernel, and so the unpredictable bits of the size 
parameter will embody sufficient entropy to thwart RC4-PRNG attacks.

Well? Has anyone looked at ...
[ message continues ]

Haven't you done this already? So you don't know what you are accusing someone off something.
No... I didn't read it also, but i'm not entering this discusion with my 'believe'

[ message continues ]