Random numbers from CPU execution time jitter
Random numbers from CPU execution time jitter
Posted May 7, 2015 13:06 UTC (Thu) by ksandstr (guest, #60862)Parent article: Random numbers from CPU execution time jitter
A 2 KiB buffer will fit entirely into any L1 cache since 1998-ish. The only mainstream exception are the Pentium 4 "NetBurst"'s earliest models with their (even at the time) tiny L1d set-ups -- and even those were 2 KiB twice over.
Granted, it's almost guaranteed that a rarely-touched 2 KiB buffer would be at least partially cold if the entropy-mixing code is cold also, however, 1) that's not what the article says, and 2) an entropy mixer's behaviour should remain consistent regardless of how hot its own code path and/or accessory buffer is.
These are characteristics of poorly-understood code that merely appears to do the right thing, rather than provably doing so even in the face of attempted compromise. Experience shows that poorly-understood but established code (i.e. black magic), such as what this has the potential to become, is very difficult to remove even in the face of grave failure[0]. Considering that the cache and/or hardware counter behaviour of future architectures may change arbitrarily, there's little value in poorly-defined cache latency shenanigans such as this over their humble-but-obvious "read counter, stir pool w/ low 2 bits" counterpart.
[0] say, predictable crypto keys as from Debian's valgrind olympics: a black-magic issue because of valgrind's status as monolithic and incomprehensible making it an object of authority.
Posted May 7, 2015 16:29 UTC (Thu)
by itvirta (guest, #49997)
[Link]
valgrind or openssl?
Random numbers from CPU execution time jitter
> black-magic issue because of valgrind's status as monolithic and
> incomprehensible making it an object of authority.