ntpkeygen patch

Fri Jan 6 23:16:23 UTC 2017

I wish somebody had mentioned to me that we wrote ntpkeygen in Python
last month so that I could have done a code review. I now have, and
fortunately, it appears as correct as can be for a Python-based
implementation.

But that qualifier is important. I'm not thrilled that we're now
relying on Python's SystemRandom implementation in lieu of libsodium,
as I suspect the latter has a lot more expert eyeballs on it. I just
looked at the Python 2.7 version (which is what #!/usr/bin/env/python
is going to get you on most distro) and it doesn't have
sys_getrandom() support. (but Python 3.5 does). This means that on
Linux it'll just read from /dev/urandom. sys_getrandom() is safer
because if you call it during early boot, it'll block until the
entropy pool is adequately seeded. /dev/urandom never blocks, which
means that it's possible to unknowingly obtain predictable output.

In any case, please *don't* switch to reading from /dev/random, or
monitoring /proc/sys/kernel/random/entropy_avail, or any similar hack.
The notion that it's ever possible to "run out" of entropy once the
pool has been seeded with an adequate quantity is based on an
insidious misunderstanding of how CSPRNGs work.

Also, it's probably best not to pass anything at all as a seed
argument to SystemRandom. On platforms where SystemRandom is correctly
implemented, the argument is just ignored, and if there are any
platforms where it's incorrectly implemented, then passing a weak seed
like getpid() will simply make it harder to notice that we've got a
catastrophic vulnerability (this is exactly how the infamous Debian
RNG bug went unnoticed for so long).

On 1/6/17, 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'm not the NTPsec crypto expert, the IETF RFC export, the NTP protocol
> expert, or a Python expert, and I have never touched the code in
> question.
>
> I not even a big Python fan.
>
> Most of what I do is make sure issues move along on a day to day basis
> and that the right people get involved in the right issues as they come
> up.
>
> 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.
>
> I'll also repeat that your finding that the seed variable to
> SystemRandom was unused is correct, and that I filed a bug report on
> the doc.  That issue was marked a "won't fix":
> http://bugs.python.org/issue29161?
>
> Sadly this mirrors my previous unproductive experiences with the Python
> developers.
>
> 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.
>
> 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.
>
> 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?
>
> 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.
>
> 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.
>
> Did I miss any questions?  I wish I had answers...
>
> 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
>
>
>