Entropy loss [LWN.net]

Entropy loss

Posted Sep 18, 2019 10:58 UTC (Wed) by patrakov (subscriber, #97174)
In reply to: Entropy loss by nilsmeyer
Parent article: The 5.3 kernel is out

In the kernel: explicit ban my Ted T'so (because it is not known how much entropy is in the resulting bitstream), in the initramfs: it's possible but nobody does it because they don't realize the need.

to post comments

Entropy loss

Posted Sep 18, 2019 14:17 UTC (Wed) by kazer (subscriber, #134462) [Link] (1 responses)

I'm not really sure what you are saying, but it is different to generate randomness sufficient for cryptography ("keep this secret" such as filesystem encryption) and just a random value ("guess my number" such as Xorg MIT cookie). X cookie is particularly bad case to use crng since X security is laughable in other ways already.

In this case reducing file-IO also reduced entropy for crypto-randomness, which was abused by Xorg, which really has not benefit from that level of randomness at all.

Entropy loss

Posted Sep 18, 2019 14:38 UTC (Wed) by patrakov (subscriber, #97174) [Link]

I am saying that a modern CPU (as opposed to an ancient Z80) already has a lot of complex unsynchronized clocks and delays within itself and within the memory controller. Just running a specific, carefully chosen set of instructions (that touch memory and perform arithmetic operations) is guaranteed to take slightly unpredictable time due to "beats" between these independent clocks, even if single threaded, even with interrupts disabled, and even if there is absolutely nothing else running.

So there is, in fact, an unintentionally-created hardware random number generator in every system which does not derive all clocks from a single crystal. There is software ("haveged") that repeatedly benchmarks this kind of instruction sequence using either a high-resolution timer or a cycle counter, and claims to extract entropy from that. Even without RDRAND, and it also works on many non-x86 CPUs. E.g., on mips 24kc in my TP-Link Archer C7, it gets around 200 kilobytes of random data per second. There is also a cryptoapi-based implementation of the same idea in the kernel, and a modern version of "rngd" also has this code. But there are also claims that the output is actually not random (despite passing statistical tests for randomness) and should not be trusted.