Yo Greg! On Fri, 06 Jan 2017 05:52:29 +0000 Greg Rubin <[email protected]> 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 [email protected] Tel:+1 541 382 8588
pgpB9nfrxlC7l.pgp
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________ Linuxptp-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
