<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 1/24/20 11:35 AM, Peter Todd wrote:<br>
</div>
<blockquote type="cite"
cite="mid:4F326E33-334A-449E-B2ED-19DF3171089D@petertodd.org">
<pre class="moz-quote-pre" wrap="">On January 23, 2020 8:26:43 PM EST, Ryan Carboni <a class="moz-txt-link-rfc2396E" href="mailto:ryacko@gmail.com"><ryacko@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On Thu Jan 23 11:25:55 EST 2020, Theodore Y. Ts'o wrote:
</pre>
<br>
<pre class="moz-quote-pre" wrap="">public/private keypair the first time it is plugged into AC mains,
</pre>
<pre class="moz-quote-pre" wrap="">
each outlet in your house has a different voltage
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
While it's true that the voltages will be different, every outlet will have the same phase (modulo the trivial 180° out of phase you see due to split power). So this is irrelevant to anything about random number generation.
</pre>
</blockquote>
<p>[I should have sent this sooner. Might be too stale, if
moderators kill it I'll not object.]<br>
</p>
<p>When looking for entropy, sample every input one can from the
real world. And if one if looking for entropy that is unknown to a
distant foe, sample local things. In addition, do it at a moment
that is unknown to that distant foe. Maybe when a human physically
plugs it in--another case of sampling something local, a human. </p>
<p>For a project I worked on that wanted entropy I sampled every
voltage and temperature I could find, every serial number I could
find, I sampled fan RPMs, I hashed startup contents of DRAM (this
was a vintage when these parts did not initialize to zeros). I
also initialized the stored pool from a mouse-equipped computer at
"manufacturing" time. I regularly saved the pool in a cron job (to
minimize a reboot after a crash replaying from a previous state).
This was also a time when the Linux urandom maintainer was busily
turning off all interrupt timing as entropy sources, on some damn
purity grounds (stupid!), so I compiled a custom kernel turning
them back on.<br>
</p>
<p>In the case of AC power, sure, at a gross level it will be the
same phase--across a very large region. But the powerlines are an
antenna and each outlet is getting different local reception, so
there is going to be local information there that is not available
elsewhere. That looks tasty if I'm looking for entropy. (Always
hash accordingly.) <br>
</p>
<p>Doing detailed sampling of the AC is expensive, but measuring
phase could be pretty cheap...and, exactly when an embedded device
is plugged in (and the phase when it first gets around to
measuring it) isn't something that is easy for a remote foe to
learn. Hell, it isn't easy for a really sophisticated near foe to
learn. Phase, based on, say, millisecond-quality measurement,
seems valuable; there are obvious ways to attack it, but oh my
God, they are expensive. If one is designing a cheap device
manufactured in volume scale will not be on the side of the
attacker.</p>
<p>We should quit being so pure about "entropy" and be pleased for
any <i>local</i> information that <i>remote</i> attackers can't
easily know. The real world matters for RNGs, implementation
matters (stupid things like, are your entropy sources not wired up
in the first place?, or are you giving away your pool somehow?),
and physical dimensions matter: If your attacker can't get closer
than some minimum range, and there is going to be local
information that is hard for the attacker to know (speed of light,
lossy "signal lines", and inelastic mechanics are your friends).
Will there be phase jitter in an on-chip, multi-GHz,
pseudo-spread-spectrum, analog PLL? Yes! Looks as good as
"entropy" to me: at least if ones foes are forced to be more than
a few mm away, and if they aren't that far away? You have far
bigger problems.</p>
<p>RNGs are an engineering problem. That means theory applied to
practical reality.<br>
</p>
<p>-kb<br>
</p>
</body>
</html>