[Cryptography] In search of random numbers

Lodewijk andré de la porte l at odewijk.nl
Thu Oct 23 06:20:47 EDT 2014


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.

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.

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.

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 :)

(don't forget to put the #cycles-between-calls-to-random-generator in a
ring-array)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20141023/4d8b6956/attachment.html>


More information about the cryptography mailing list