Re: Very platform dependant
Hey Red Ted,
JV Roig here, the cited paper author.
Testing on embedded devices is indeed a problem. However, I have tested on a lot of platforms that are a good stand-in to the embedded device market:
-Raspberry Pi 3 (quad core, ARM Cortex A53, 1.2GHz, in-order-execution)
-Raspberry Pi 1 (single core, ARM11, 700 MHz, in-order-execution)
-Arduino Uno (ATmega328p, 16MHz, in-order-execution, low-res timer only [4-microsecond precision])
The worst case for my micro-benchmark timing aggregation technique (or "SideRand" as still cited in this article and paper, but that's the old name) is the Arduino Uno. Yet, even there, gathering 3,000 bits of entropy per second was achieved. So for now, I'm pretty confident that micro-benchmark timing aggregation will work on all sorts of devices, embedded to giant servers.
HWRNG randomness "audits" are unfortunately easily spoofed as these can only measure the output, and not really infer anything about the source. Imagine a malicious HWRNG that merely iterates through the digits of pi, say, 10-20 digits at a time, and hashes that using SHA256 to give you 256-bits of randomness. That'll look super random and pass every test. But, seeing just one output, the adversary who backdoored that to use pi digits can easily predict what the next one is, and what numbers you have gotten previously.
Or imagine Intel's Secure Key HWRNG. The final step it does, if I remember correctly, is AES output. If it's basically AES-CTR DRBG, then it could just be incrementing a hard-coded key (from whatever favorite boogeyman you have, like the NSA or Cobra). It will pass every single test you throw at it, and the NSA can still perfectly predict the output.
In a nutshell, all that a statistical test can tell you is that there aren't any obvious patterns, and that your HWRNG isn't obviously broken. Whether it's actually unpredictable is an entirely different issue.