Re: Timings for random

2017-01-30 Thread Gary E. Miller
Yo Hal! On Sun, 29 Jan 2017 17:15:05 -0800 Hal Murray wrote: > g...@rellim.com said: > > You can't run out of randomness with RAND_bytes(). > > Would you please say more. The man page says: > >RAND_bytes() puts num cryptographically strong pseudo-random > bytes into buf. An error oc

Re: Timings for random

2017-01-29 Thread Sanjeev Gupta
On Mon, Jan 30, 2017 at 9:15 AM, Hal Murray wrote: > How can I be sure that it has "been seeded with enough"? Why would OpenSSL lie? :-) -- Sanjeev Gupta +65 98551208 http://www.linkedin.com/in/ghane ___ devel mailing list devel@ntpsec.org http:

Re: Timings for random

2017-01-29 Thread Mark Atwood
I wonder if we should just start recommending that people plug one of Keith Packard's ChaosKey's into a USB port on their NTP boxes. https://keithp.com/blogs/chaoskey/ I just leave one plugged into my main working NUC all the time. ..m On Sun, Jan 29, 2017 at 5:15 PM Hal Murray wrote: > > g..

Re: Timings for random

2017-01-29 Thread Hal Murray
g...@rellim.com said: > You can't run out of randomness with RAND_bytes(). Would you please say more. The man page says: RAND_bytes() puts num cryptographically strong pseudo-random bytes into buf. An error occurs if the PRNG has not been seeded with enough randomness to en

Re: Timings for random

2017-01-29 Thread Gary E. Miller
Yo Hal! On Sat, 28 Jan 2017 23:19:32 -0800 Hal Murray wrote: > g...@rellim.com said: > > rand() and RAND_pseudo_rand() are not random, just psuedo random, > > thus not for NTP. > > Do you think fuzzing needs cryptographically strong randomness? You are asking the wrong guy. I'm not sure we

Re: Timings for random

2017-01-29 Thread Eric S. Raymond
Hal Murray : > > What about the OpenSSL RAND_bytes()? > > It's slightly faster than RAND_pseudo_bytes() :) ?? And what we're now using. I finished the cleanup last night; everything goes through OpenSSL now, the local MD5 and SHA-1 code is gone, and the depenendency on libsodium has been abol

Re: Timings for random

2017-01-28 Thread Hal Murray
g...@rellim.com said: > rand() and RAND_pseudo_rand() are not random, just psuedo random, thus not > for NTP. Do you think fuzzing needs cryptographically strong randomness? I timed RAND_pseudo_bytes() rather than RAND_bytes() because I didn't want to get mixed up with not enough randomness and

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. N

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

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

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