Problems emerge for a unified /dev/*random
&quot;Nobody knows what entropy really is, so in a debate you will always have the advantage.&quot;<p>~ Claude Shannon<p>I&#x27;ve become more and more uncomfortable with the word &quot;entropy&quot; as used in cryptography. The word &quot;random&quot; has always been problematic. I try to use &quot;unpredictable&quot; instead, because I have half a clue what that word means.<p>I think &quot;entropy&quot; is used to mean &quot;unpredictable <i>in principle</i>&quot;, which would exclude chaotic processes like CPU jitter. Chaotic processes like the weather are predictable in principle; but they are so complex that in practice they are unpredictable. Quantum processes such as radioactive decay or tunneling seem to be unpredictable in principle. If it&#x27;s unpredictable, then to my mind it&#x27;s sufficiently unpredictable for cryptography.<p>The Intel HWRNG depends on chaos - the jitter in gate propagation times. I&#x27;d settle for that, if it weren&#x27;t for the fact that the raw chaos from the process isn&#x27;t available for inspection - you can only see the result of obfuscating it using AES. How much bias is there in the raw bitstream from the unencrypted HWRNG output? I have no way of finding out.<p>Entropy accounting in the Linux RNG seems to be somewhere between heuristics and guesswork. It seems to be awfully complicated, given that it comes down to finger-in-the-air estimates.<p>&#x2F;me not a cryptographer, mathematician or physicist.