<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 15/03/2024 04:04, Jim Cheetham
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:5a699870-4e36-42ed-95bd-1e7cae015736@app.fastmail.com"><span
style="white-space: pre-wrap">
</span>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">I suppose it is very hard to quantify if an entropy pool resulting
from the Linux CSPRNG running for time t is any "better" for having
some entropy mixed in from a gadget vs. if it had just been left to
extrapolate from its initial seeding by RDRAND and CPU timings etc.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
A long time ago I had wanted to run an experiment on boot times & moving data across ssh & tls services, on a large fleet of VMs. Sadly never managed to do it; it would have made a nice measurement for sysadmin operations. I don't think that under a current kernel there's any speed benefit any more.
However, a large part of "having multiple entropy sources" is to protect you from attacks or errors on the default sources. This is probably still a valid proposition :-)
And of course, generation of random numbers for non-operating-system features is still valid. PRNGs (even CSPRNGS) are not "the same" as actual entropy sources.
</pre>
</blockquote>
<p>Hi Jim,<br>
</p>
<p>It used to be that entropy was the focus and also the measure.
But that proved too difficult - it is very hard to reliably
estimate entropy, in large part because the part can break and
deliver zero entropy and you can't tell.<br>
</p>
<p>Early designs followed the Schneier concept of measuring the
entropy in a pool and then stirring in some more when needed from
a trusted source. But that didn't make for simple coding.</p>
<p>Since then, thinking has changed:</p>
<p>1. seek not entropy but surprise. The former is a physical
quality, whereas the latter is a human quality. Who is your
attacker? You just need to surprise him with numbers he can't see,
they don't need to be high entropy at all, they just need to be
unpredictable *by your attacker*.</p>
<p>2. NB that if your attacker is on your machine, and can read
everything, then it makes no difference if it is entropy or
surprise...</p>
<p>3. Instead of relying on one perfect entropy engine, rely on
several poor quality devices. 3 or even 6 of them. As long as
they are independent, they all help.</p>
<p>4. Then mix it all together, and shove it through a
cryptographically secure hash function. Ie one that cannot be
looked back through. Typically people use an encryption algorithm
for this.</p>
<p>5. Enjoy! I first wrote this up back in 2014
<a class="moz-txt-link-freetext" href="https://iang.org/ssl/hard_truths_hard_random_numbers.html">https://iang.org/ssl/hard_truths_hard_random_numbers.html</a></p>
<p><br>
</p>
<p>iang<br>
</p>
<p><br>
</p>
<p><br>
</p>
</body>
</html>