> Well, if you had say a single thread collecting data to feed an entropy > pool, once an attacker syncronized on that, they'd win.
Cross-correlation data doesn't really support the assertion that they win. As depicted in last my message most favorable synchronization scenario on multi-core CPU exhibited 0.17 maximum correlation coefficient for low lags. Naturally one can argue that 0.17 is bad enough... So I had closer look. Earlier I wrote "probably most relevant thing about it is maximum at 0 (hardly seen)". Zooming in revealed that the maximum [of 0.17] is not at 0, but at 200, and that there is super-high spike in input data there, several times higher than even timer interrupts. As for high spikes per se, consider following test. Generate two sets of 128K data points uniformly distributed between 0 and 1. Cross-correlation vector is 0.012 at most and 0.0022 in average, and can be considered "good", right? Now assign 100 to first elements of both vectors. "All of a sudden" cross-correlation vector has maximum at 0.48. 0.48 looks bad, doesn't it? But the data is still *perfectly* usable. In other words, high spikes have rather strong masking effect and make it hard and counterintuitive to interpret cross-correlation data. So I've attempted to %=1024 every point of referred most-favorable-synchronization data set. Resulting cross-correlation vector is attached, maximum is 0.026, mean value - 0.0035. Arguably synchronized thread hardly gets advantage... If anything, spying thread would probably ... improve data for victim. > There's one more point. The upper bits of those registers are easier to > guess than the lower, again the 'fix' is obvious, what's more difficult is > knowing which of the lower bits are actually changing. Recall that OPENSSL_instrument_bus collects *differences* between clock counter readings. > i.e. P4 the lower 4 bits are effectively 'stuck' as every instruction is a > multiple of 16 clocks long, quite a few processors have quirks here. I don't see that it's relevant. Indeed, consider following mental exercise. As mentioned on referred page, number of values the samples take is limited, e.g. 85 is referred example. So let's write them down in table and whenever we run into value X, let's return its index in the table. Now there are no 'stuck' bits, but did we make data more fit for seeding PRNG? Not a bit. The only thing you have to care about under circumstances is entropy, not specific sample values. "Seeding PRNG" refers to RAND_add.
<<inline: mod1024.jpg>>
