<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jan 20, 2016 at 10:47 AM, Kent Borg <span dir="ltr"><<a href="mailto:kentborg@borg.org" target="_blank">kentborg@borg.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 01/20/2016 11:30 AM, Thierry Moreau wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 20/01/16 01:37 AM, Bill Cox wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
These problems are fixable.  Health monitors with good entropy<br>
estimators should be required for each entropy source.<br>
</blockquote>
<br>
Those who maintain the Linux kernel are not in a position to *require* either health monitors or good entropy estimators. The inclusion of an entropy source in a system is a decision that may be made even after the Linux distribution packaging.</blockquote></span></blockquote><div><br></div><div>I was unclear.  I meant to say that rngd, or some daemon like it, should require health monitors and good entropy estimators.  I agree this is out-of-scope for the kernel, but a good hardware RNGD utility daemon like rngd should provide this, IMO.  Developers of TRNGs should be encouraged to provide raw bits, and a decent model, and leave the rest to the rngd devs.</div><div><br></div><div>Getting this stuff right is hard.  Hiding the raw bits makes it even harder.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The kernel cannot make a perfect RNG, there are system issues that are bigger than just the kernel's responsibility. The kernel needs to do the best job it can but...<br>
<br>
<br>
A few years ago the Linux urandom maintainer seemed to be turning off every entropy source he could because none of them were well enough characterized for him. Crazy! (Then Ted took over again, thank God.)<br>
<br>
It is important to have some entropy making its way in, but there is a logical extreme here to avoid: don't discard all your entropy just because none of it is perfect.<br>
<br>
Heck: give me a backdoored RNG (the new NSA one!), and give me another backdoored RNG (what is Intel's old RNG opcode?), and I'll mix them together--maybe use the CPU temperature to control how the two backdoored RNGs slide across each other in time. And let me mix in the timestamp counter at every interrupt and let me mix in the most recent value of the Dow Jones Industrial Average and a few books off Project Gutenberg. And keep the attackers out of my box and a few meters away---and I will have a great RNG.<br></blockquote><div><br></div><div>Agreed.  Every source of entropy, even one with a back-door, is welcome in the entropy pool.  The trick is maintaining a good guestimate of secure entropy.  Physical models and health monitors can help with entropy estimates, though back-doors are still possible.  Multiple sources can help with security.  The problem I saw in my version of rngd (which may be old - I did not check upstream) is that it did not have a way to require multiple entropy sources to contribute significant entropy.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It is important to know the RNG isn't spitting disguised zeros, and that is hard. But mixing in complete crap--with something good--should not be a problem. Don't excise everything that you can't prove is perfect.<br></blockquote><div><br></div><div>I agree.  All (potential) sources of entropy are welcome.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Someone on this list liked to dismiss stuff as "squish". I say go ahead and put in lots of squish. I know I would rather crack a simple RNG with only a few inputs that can be well characterized than a chaotic RNG with tons of inputs I would have to track.</blockquote><div><br></div><div>Hmm... How about when I use a single very well characterized TRNG, for which I can prove that the entropy contributed on each update to /dev/random is at least 400 bits with extremely high probability?</div><div><br></div><div>I guess it depends on what you mean by cracking.  If you mean hacking in user space to defeat all sources of entropy feeding /dev/random, I agree.  It is simpler to hack one source than several.  However, if you mean an attack that attempts to guess the output from /dev/urandom, I would prefer to defend against this with one known-good source over multiple questionable ones.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Just making sure your RNG isn't flat out broken is really, really important and not so easy. Making sure it is perfect is a distraction.</blockquote><div><br></div><div>Yep.  It is simple enough to just throw more somewhat imperfect bits of entropy at the problem than polishing each one to be sure we understand it 100%, so long as we can be confident that the bits contain _some_ entropy.</div><div><br></div><div>Bill </div></div></div></div>