<div dir="ltr"><div class="gmail_extra">There's typically a low bandwidth and there's precious little entropy in it (only non-engineered spam can count as entropy). Using hashes you can just throw more and more information at it, some if it is bound to stick.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The question is, why not just hash the entire memory? Then just stream all the inputs into arrays (% arraylength; ring arrays), and voila, absolute maximum entropy collected.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Hashing the entire memory can be extremely parallel. Even just a kernel modification that marks un-rehashed blocks, and partially rebuilds a hash-tree dynamically (based on oldest changed memory block) would be guaranteed to collect all that good stuff. The block size and rehash rate(s) could be adjusted for better performance. To ensure/enlarge entropy carry-over you can include the previous memory-block-hash into the next memory-block-hash. You can even dynamically decide to rehash more marked blocks when more entropy is being consumed from /dev/random or /dev/urandom. Someone would have to do some modelling and testing to see how many bits of entropy are actually squeezed out of the system, but it's totally possible. And (in instant-rehash mode) guaranteed to be the most entropy one can squeeze out of a system. </div><div class="gmail_extra"><br></div><div class="gmail_extra">It's not the most efficient, but it might very likely beat the mail-log tactic in terms of bits-of-entropy-obtained/computing-resources-eaten. Depending on how much quality spam you receive, I guess :)</div><div class="gmail_extra"><br></div><div class="gmail_extra">(don't forget to put the #cycles-between-calls-to-random-generator in a ring-array)</div></div>