ntpkeygen patch

[Greg Rubin]

Gary,

On Fri, Jan 6, 2017 at 12:34 PM Gary E. Miller <gem at rellim.com> wrote:

> Yo Greg!
>
> On Fri, 06 Jan 2017 05:52:29 +0000
> Greg Rubin <grrubin at gmail.com> wrote:
>
> > I'm still very interested in reading your longer response to my
> > comments regarding entropy and key generation. This is something I
> > commonly encounter in Python code and if there is a better way to
> > manage things, I'd like to know.
>
> I'll repeat that one-to-one email is not the best place for this
> discussion.
>

(I just didn't feel the need to include the ping on the public thread.)

...
> I'll repeat that I added a warning to the ntpkeygen man page about
> not running the program in a script, or near startup, and to ensure that
> your host has sufficient entropy before running it.
>

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.

...
> I'll also repeat that I'm holding off applying your patch, which basically
> removes a NOP, until a patch comes along that implements the intent, not
> the reality, of the current code in question.
>
> That said, I have little new to offer, just more data on how not to
> proceed.  No new code, or suggestions, have come forth.  When I'm
> silent it usually means I'm out of ideas.
>
> I just studied the current thinking on /dev/urandom and the consensus
> seems to be to just trust urandom, as long as you know you have
> sufficient entropy available.  If you can't trust your urandom
> then your problems are too big for us to solve.
>
> 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.


> That just leads to more unanswered questions.
>
> Can we tell how much entropy is available?  Sadly Python has no way to
> query the urandom entropy pool, so no way to portably code a test for
> that. Linux has /proc/sys/kernel/random/entropy_avail, but NTPsec runs
> on a lot more than Linux.
>

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.


>
> Can we add entropy to the pool?  I played with this a bit.  The
> traditional trivial suggestion is to move the mouse or read the disk.
> Obviously the mouse move does not work on a server, and reading the disk
> only helped trivially.  Playing streaming music helped not at all. The
> best thing seemed to be to run ssh, but even that added trivial entropy.
> Best to just wait a while after boot for entropy to naturally happen.
> Or maybe add a hardware RNG?
>
> 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.


> Can we postprocess the urandom entropy to get more entropy?  Sadly
> no, that just adds obfuscation to whatever randomness is already in
> urandom.  NTPsec is FOSS so we can not even obfuscate well.  So the
> current stirring in ntpkeygen is fun, but not useful against an attacker
> that can predict our urandom output.
>

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.


> Does it even matter?  The NTP MD5 message digest is thought to be too
> weak for serious use.  That is why NTS is working on a better algorithm
> that makes this all obsolete.  Any potential weakness in a key is
> overshadowed by the weakness of the digest protocol.
>
>
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.


> Did I miss any questions?  I wish I had answers...
>
>
Don't we all. This is why I keep physical dice by my desk. There are times
when that is the only answer.

Greg

So, nothing really new for me to report.  If nothing new happens in a
> few days I'll just apply something like your patch, giving you credit
> for it, and put this aside for a while.  No other action items have
> been suggested, but maybe I missed one?
>
> As always, suggestions welcome, but we seem to be out of good ones on
> this subject.
>
> TK;DR; keep your entropy high, get the next digest algorithm standardized
> and implemented.  Maybe get a good HWRNG.
>
> RGDS                                                 Veritas liberabit vos
> GARY                                                     Quid est veritas?
> ---------------------------------------------------------------------------
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> gem at rellim.com  Tel:+1 541 382 8588 <(541)%20382-8588>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20170107/b21543f0/attachment.html>