Re: Timings for random

2017-01-28 Thread Gary E. Miller 
Yo Kurt!

On Sat, 28 Jan 2017 23:18:01 +0100
Kurt Roeckx  wrote:

> > rand() and RAND_pseudo_rand() are not random, just psuedo random,
> > thus not for NTP.  
> 
> I have no idea what you're using random numbers for, but if
> unpredicable is what you want rand() is probably not what you
> want.

NTP uses random numbers for three reasons:

1. To generate crypto keys: ntpkeygen

2. To add to the LSB's of time stamps as a nonce

3. To use as fuzz around very small time measurements.

The dirst is Python, the later two are C code that will be using only
OpenSSL soon.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin


pgp0EhwX8wgCO.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Timings for random

2017-01-28 Thread Kurt Roeckx 
On Sat, Jan 28, 2017 at 12:48:34PM -0800, Gary E. Miller wrote:
> Yo Hal!
> 
> On Sat, 28 Jan 2017 12:39:02 -0800
> Hal Murray  wrote:
> 
> > Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz
> > Stdlib: 100 calls to rand() took 0.021 microseconds each
> > Sodium: 100 calls to randombytes_buf() took 0.367 microseconds
> > each 
> > OpenSSL: 100 calls to RAND_pseudo_bytes() took 0.630
> > microseconds each
> 
> rand() and RAND_pseudo_rand() are not random, just psuedo random, thus
> not for NTP.

I have no idea what you're using random numbers for, but if
unpredicable is what you want rand() is probably not what you
want.

> What about the OpenSSL RAND_bytes()?

RAND_pseudo_rand() has been deprecated anyway. The only difference
in behaviour was when it didn't get seeded properly.


Kurt

___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: Timings for random

2017-01-28 Thread Gary E. Miller 
Yo Hal!

On Sat, 28 Jan 2017 12:39:02 -0800
Hal Murray  wrote:

> Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz
> Stdlib: 100 calls to rand() took 0.021 microseconds each
> Sodium: 100 calls to randombytes_buf() took 0.367 microseconds
> each 
> OpenSSL: 100 calls to RAND_pseudo_bytes() took 0.630
> microseconds each

rand() and RAND_pseudo_rand() are not random, just psuedo random, thus
not for NTP.

What about the OpenSSL RAND_bytes()?

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin


pgpNziWjr7gPE.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Timings for random

2017-01-28 Thread Hal Murray 
Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz
Stdlib: 100 calls to rand() took 0.021 microseconds each
Sodium: 100 calls to randombytes_buf() took 0.367 microseconds each
OpenSSL: 100 calls to RAND_pseudo_bytes() took 0.630 microseconds each


Raspberry Pi 2
model name  : ARMv7 Processor rev 5 (v7l)
BogoMIPS: 57.60
Stdlib: 100 calls to rand() took 0.161 microseconds each
Sodium: 100 calls to randombytes_buf() took 5.901 microseconds each
OpenSSL: 100 calls to RAND_pseudo_bytes() took 9.202 microseconds each

Those are in a timing loop, so round up for loading the cache.


-- 
These are my opinions.  I hate spam.



___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: sockaddr_storage

2017-01-28 Thread Eric S. Raymond 
Hal Murray :
> 
> e...@thyrsus.com said:
> >> Are there any places left in the code that are storing addresses in
> >> packed-4-octets or ints?
> > These are areas I will have to investigate.  
> 
> I think the storage is all sockaddr_u
> 
> I think all the printout goes through socktoa in libntp/socktoa.c

That's what I think, too, but I haven't verified it yet.

> I will punt any DNS changes until after your work in this area.

I don't think you need to, or should.

"Need to" because the DNS-threading stuff is pretty well sparated from
anywhere the IPv4/IPv6 stuff matters.  "Should" because removing sockaddr_u
has fallen way down my priority list. Because of the footprint issue I
probably won't do it all except as part of the immediate run-up to a
Go translation of the code, assuming we decide to go that route.

> If ntpdig is no longer around, is there any reason for libntp?

Two minor ones.  One is that part of libntp is used to build the Python
extension used by ntpq, etc. The other is that there's a separation
between ntpd and libntp test code parallel to the library split -
not a problem per se but it increases the friction cost of reorganizing.

It's on my to-do list to try moving one of the libntp modules that isn't
used in the Python extension over to ntpd/ as a test of how much trouble it
is.  If it's no big deal I'll move everything not used in the Python
extension.

BTW, I've successfully turfed out the ISC MD5 code.  This dropped about
300LOC.  Still need to get rid of the local SHA-1 and remove the
libsodium dependency.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel