ntpkeygen patch

[Gary E. Miller]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20170106/ce08c2c9/attachment.bin>