<div dir="ltr">Gary,<div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jan 6, 2017 at 12:34 PM Gary E. Miller <<a href="mailto:gem@rellim.com">gem@rellim.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yo Greg!<br class="gmail_msg">
<br class="gmail_msg">
On Fri, 06 Jan 2017 05:52:29 +0000<br class="gmail_msg">
Greg Rubin <<a href="mailto:grrubin@gmail.com" class="gmail_msg" target="_blank">grrubin@gmail.com</a>> wrote:<br class="gmail_msg">
<br class="gmail_msg">
> I'm still very interested in reading your longer response to my<br class="gmail_msg">
> comments regarding entropy and key generation. This is something I<br class="gmail_msg">
> commonly encounter in Python code and if there is a better way to<br class="gmail_msg">
> manage things, I'd like to know.<br class="gmail_msg">
<br class="gmail_msg">
I'll repeat that one-to-one email is not the best place for this discussion.<br class="gmail_msg"></blockquote><div> </div><div>(I just didn't feel the need to include the ping on the public thread.) </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">...<br class="gmail_msg">
I'll repeat that I added a warning to the ntpkeygen man page about<br class="gmail_msg">
not running the program in a script, or near startup, and to ensure that<br class="gmail_msg">
your host has sufficient entropy before running it.<br class="gmail_msg"></blockquote><div><br></div><div>This sounds like an excellent caution to give users. Any long-lived system (especially non-virt) or with a modern processor (due to RDRAND) should have more than sufficient entropy.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
...<br class="gmail_msg">
I'll also repeat that I'm holding off applying your patch, which basically<br class="gmail_msg">
removes a NOP, until a patch comes along that implements the intent, not<br class="gmail_msg">
the reality, of the current code in question.<br class="gmail_msg">
<br class="gmail_msg">
That said, I have little new to offer, just more data on how not to<br class="gmail_msg">
proceed.  No new code, or suggestions, have come forth.  When I'm<br class="gmail_msg">
silent it usually means I'm out of ideas.<br class="gmail_msg">
<br class="gmail_msg">
I just studied the current thinking on /dev/urandom and the consensus<br class="gmail_msg">
seems to be to just trust urandom, as long as you know you have<br class="gmail_msg">
sufficient entropy available.  If you can't trust your urandom<br class="gmail_msg">
then your problems are too big for us to solve.<br class="gmail_msg">
<br class="gmail_msg"></blockquote><div>This really is the consensus. We simply have to trust /dev/urandom (or equivalent on other systems) and there really isn't a good way to improve its entropy (not without lots of extra work which is as likely to lower our security as improve it.) Hence the "pull the random data out and trust it" strategy.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That just leads to more unanswered questions.<br class="gmail_msg">
<br class="gmail_msg">
Can we tell how much entropy is available?  Sadly Python has no way to<br class="gmail_msg">
query the urandom entropy pool, so no way to portably code a test for<br class="gmail_msg">
that. Linux has /proc/sys/kernel/random/entropy_avail, but NTPsec runs<br class="gmail_msg">
on a lot more than Linux.<br class="gmail_msg"></blockquote><div> </div><div>This measure is a rough estimate at best. Once again, we generally need to simply trust the system to do the right thing. FreeBSD does the correct thing with blocking early on. Modern kernels will use RDRAND (if it is available) as additional input which will reduce (or eliminate) the risks associated with young or virtualized systems.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
Can we add entropy to the pool?  I played with this a bit.  The<br class="gmail_msg">
traditional trivial suggestion is to move the mouse or read the disk.<br class="gmail_msg">
Obviously the mouse move does not work on a server, and reading the disk<br class="gmail_msg">
only helped trivially.  Playing streaming music helped not at all. The<br class="gmail_msg">
best thing seemed to be to run ssh, but even that added trivial entropy.<br class="gmail_msg">
Best to just wait a while after boot for entropy to naturally happen.<br class="gmail_msg">
Or maybe add a hardware RNG?<br class="gmail_msg">
<br class="gmail_msg"></blockquote><div>On systems with /dev/urandom, you can write data to it and it will be mixed into the entropy pool. Other systems may have other ways of accomplishing this.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Can we postprocess the urandom entropy to get more entropy?  Sadly<br class="gmail_msg">
no, that just adds obfuscation to whatever randomness is already in<br class="gmail_msg">
urandom.  NTPsec is FOSS so we can not even obfuscate well.  So the<br class="gmail_msg">
current stirring in ntpkeygen is fun, but not useful against an attacker<br class="gmail_msg">
that can predict our urandom output.<br class="gmail_msg"></blockquote><div><br></div><div>There are post-processing steps which can be taken which will reduce the risks associated with certain problems. (For example, even if RDRAND is backdoored it can still likely be used as part of (re)seeding another PRNG which will likely be safe to use. This actually is what Linux appears to do: use RDRAND as one of several inputs into another PRNG.) However, this probably isn't worth it at our level. (That said, I haven't read through your threat model or assumed attackers, so I could well be wrong here.) Like my earlier note regarding getting extra entropy, it would add lots of complexity to the code and is likely to introduce problems as fix them.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Does it even matter?  The NTP MD5 message digest is thought to be too<br class="gmail_msg">
weak for serious use.  That is why NTS is working on a better algorithm<br class="gmail_msg">
that makes this all obsolete.  Any potential weakness in a key is<br class="gmail_msg">
overshadowed by the weakness of the digest protocol.<br class="gmail_msg">
<br class="gmail_msg"></blockquote><div><br></div><div>This is probably a key point. MD5 is broken and the keys we're already generating are likely at higher security level than the algorithms using them can support. Poor entropy is unlikely to be our downfall, currently.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Did I miss any questions?  I wish I had answers...<br class="gmail_msg">
<br class="gmail_msg"></blockquote><div><br></div><div>Don't we all. This is why I keep physical dice by my desk. There are times when that is the only answer.</div><div> </div><div>Greg</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So, nothing really new for me to report.  If nothing new happens in a<br class="gmail_msg">
few days I'll just apply something like your patch, giving you credit<br class="gmail_msg">
for it, and put this aside for a while.  No other action items have<br class="gmail_msg">
been suggested, but maybe I missed one?<br class="gmail_msg">
<br class="gmail_msg">
As always, suggestions welcome, but we seem to be out of good ones on<br class="gmail_msg">
this subject.<br class="gmail_msg">
<br class="gmail_msg">
TK;DR; keep your entropy high, get the next digest algorithm standardized<br class="gmail_msg">
and implemented.  Maybe get a good HWRNG.<br class="gmail_msg">
<br class="gmail_msg">
RGDS                                                 Veritas liberabit vos<br class="gmail_msg">
GARY                                                     Quid est veritas?<br class="gmail_msg">
---------------------------------------------------------------------------<br class="gmail_msg">
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703<br class="gmail_msg">
<a href="mailto:gem@rellim.com" class="gmail_msg" target="_blank">gem@rellim.com</a>  Tel:<a href="tel:(541)%20382-8588" value="+15413828588" class="gmail_msg" target="_blank">+1 541 382 8588</a><br class="gmail_msg">
</blockquote></div></div></div>