On Wed, May 27, 2015 at 3:18 PM, Russell Leidich <[email protected]> wrote: > I realize that anyone can whiten a long stream of weak entropy into a short > stream of strong entropy. But I disagree that doing so properly, in this > case, is trivial.
here is a general solution: 1, initialize a cryptographic sponge 2, absorb N bits worth of raw data (N >= 128) 3, squeeze N bits 4, goto 2 you can further optimize this by making N a multiple of the block size. you can also be less pedantic, and once you absorbed 128 bit of entropy, just use the sponge as PRNG, you don't need to input anything anymore. here is a less general, but more stable and easier solution: 1. write your data to /dev/random 2. use /dev/urandom to get data both of these methods are trivial. > Do you really think that even a "smart" attacker can model a live CPU well > enough to predict tens of thousands of unique timedelta sequences in a row? yes. it is not even that hard. in fact some compilers use CPU emulators for optimization. supposedly not perfect emulators, as i believe the actual CPU architecture is not public. however, dedicated attackers might be able to build adequate models. one of such attackers is Intel itself, having the schematics. and many older CPUs have known schematics. actually, it would be an interesting experiment. run the algorithm on an emulator, without any entropy at all, and see the output. my guess is the algorithm will continue to churn out pseudorandom data that passes randomness tests. that is because of the chaotic CPU behavior, and your whitening. > real system running enough of an OS to be interesting enough to attack, let > alone > if it has received network or harddrive packets (and in the absence of > unrelated kernel vulns and the like), whether or not it's currently > connected to the network. you see, you are still struggling with the definition of entropy. in this example, the entropy is the harddrive timing, network timing, user input, etc. guess what, it is NOT 4Mb/s, but way way less than that. and especially much less on a box packed with ssd and no user input. but my major point is that the actual entropy is *unknown*, and i see no actual attempt to find out how much. on the top of this true entropy, you have a chaotic deterministic system. it hardens analysis, but it does not generate entropy. btw it does not render your collector entirely useless. it just renders it mostly useless. this is what you actually offer: 1, simplified entropy collection by exploiting the fact that the history of CPU appears in its current internal state, and the internal state affects its timings. 2, absolutely no entropy estimation of any sort, except that it is capped by your system entropy (events outside the CPU), but can be even less. 3, non-reviewed non-cryptographic algorithm and implementation _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
