|
|
Subscribe / Log in / New account

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

> The jitter entropy module allocates a 2KB buffer during initialization that it loops through and simply adds one to the value stored there (which causes both a load and a store). The buffer is larger than the L1 cache of the processor, which should introduce some unpredictable wait states into the measurement.

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.


to post comments

Random numbers from CPU execution time jitter

Posted May 7, 2015 16:29 UTC (Thu) by itvirta (guest, #49997) [Link]

> [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.

valgrind or openssl?


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds