No specific distribution of samples necessarily speaks in favour of its
randomness. Well, one can argue that its wideness kind of does, but it's
not sufficient. Shannon entropy is not measure of randomness, but rather
redundancy of data representation. It's used to put certain value on
random data, but putting this value on any given data set doesn't tell
anything about it being random. For example you can characterize
following set by its distribution and entropy value, but it's not in any
way random.
* * *
* * * * *
* * * * *
* * *
Yes, two rdtsc's one after another is extreme example, but it was a
reaction to statement that *any* instruction sequence is subject to
variations, which is simply not true. [Recall there was "if compiled
with optimization on", but what about optimization? With optimization
off, there is a number of redundant references to memory generated by
compiler which makes output vary. But even then output is periodic and
predictable. BTW, even *if* there was some actual randomness, do we want
it to depend on user-selectable optimization level? Absolutely not.]
More complex instruction sequences do execute in predictable manner.
Because processors are *designed* that way, they are also designed to
amortize eventual deviations [in interactions with memory subsystem] and
do it pretty efficiently. And as already mentioned, OS gives *a lot* of
opportunities for processor to exercise its capacities. If found, it is
unamortized deviations that need explanation, not vice versa. In such
case they even need ways to be detected, monitored and quantified [at
run time]. "Hope that it's sufficient on another system" or vague
references to "root cause" don't really cut it. HyperThreaded thread?
Integrated graphics? Poor power supply? TurboBoost? For example
TurboBoost is driven by thermal detector and moment of transition is
likely to be viable source of real randomness, but how do you reliably
detect that it's even option on arbitrary arbitrarily loaded system?
[Keep in mind that it would make the code *highly* processor-specific].
Printing values between probes is a slippery way. Printing is capable of
introducing variations (buffer flush results in system call, which is
likely to trigger varying set of events affecting cache, branch
prediction, TLB, etc.), but one should remember that target application
won't be printing anything [at least you can't make such assumption].
Test programs should act more like target application [simply assume the
least], run experiment in memory and print results *afterwards*. Yes,
rdtsc snippet contradicts this, but think of it as following: even with
print it can be *that* predictable.
Andy, as you have access to hardware that seem to cause concerns for
the RNG, may I ask you to run the test on the entropy that I used to
generate the two pictures? The test is at
http://www.chronox.de/jent/devel/jitterentropy-20130527-devel.tar.bz2
No, I won't run it until printing is performed "off-line". And do switch
on optimization.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
