they don't require updating
On Sat, Jan 28, 2017, 5:38 PM Hal Murray wrote:
>
> Do they need to be updated? I just noticed one that was 2015.
>
> Should that go on the release checklist?
>
>
> --
> These are my opinions. I hate spam.
>
>
>
> ___
> de
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
Do they need to be updated? I just noticed one that was 2015.
Should that go on the release checklist?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
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
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
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
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
e...@thyrsus.com said:
> 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.
Just to make sure I/we understand...
The plan is to require OpenSSL and drop sodium and the local copies of
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/s
Kurt Roeckx writes:
> So as one of the OpenSSL people, it seems unrealistic to even have
> a compile time option to remove MD5 and SHA-1 at this time. Both
> are needed for TLS 1.0. It seems unrealistic that we can drop
> support for that in the next 5 years. We still support SSLv3, but
> it's disa
10 matches
Mail list logo