Entropy loss [LWN.net]

Entropy loss

Posted Sep 17, 2019 15:38 UTC (Tue) by kazer (subscriber, #134462)
In reply to: Entropy loss by patrakov
Parent article: The 5.3 kernel is out

In a static system there is no entropy. Where do you suggest it is collected from?

to post comments

Entropy loss

Posted Sep 17, 2019 15:41 UTC (Tue) by patrakov (subscriber, #97174) [Link] (5 responses)

From clock jitter, as measured by timing variations of a memory access pattern. man haveged. Of course subject to validation.

Entropy loss

Posted Sep 17, 2019 17:53 UTC (Tue) by kazer (subscriber, #134462) [Link]

Which means you need to be /running/ the system to get that. It does not just "appear" and be instantaneously available (not in the way required for crng anyway).

Entropy loss

Posted Sep 18, 2019 10:40 UTC (Wed) by nilsmeyer (guest, #122604) [Link] (3 responses)

Perhaps I don't quite understand this but wouldn't it be possible to add these sources of entropy either in the kernel or very early in initramfs?

Entropy loss

Posted Sep 18, 2019 10:58 UTC (Wed) by patrakov (subscriber, #97174) [Link] (2 responses)

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.

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.