While I cannot speak specifically to NTP, SHA (without any suffix) has been
used on other contexts to mean SHA-1. I've also never encountered SHA-0
being used in any standard. So, if NTP is actually using it and it's not
just a misunderstanding, that would be a first for me. I suspect it is
SHA-1 t
Matthew Selsky :
> Where do we get SHA-0, aka "sha", keytype support from if we remove the
> in-tree public domain version?
To my knowledge the only SHA we have in tree is SHA-1. I think you can only
get SHA-0 via OpenSSL.
--
http://www.catb.org/~esr/";>Eric S. Raymond
_
Yo Matthew!
On Fri, 27 Jan 2017 21:19:55 -0500
Matthew Selsky wrote:
> > I can only find SHA1 in ntpsec. what am I missing?
> See NID_sha in tests/libntp/ssl_init.c
I just removed a bunch of unused SSL stuff. There is still a ton
of tests for things ntpd never does.
I see no other use of N
On Fri, Jan 27, 2017 at 05:20:48PM -0800, Gary E. Miller wrote:
> Yo Matthew!
>
> On Fri, 27 Jan 2017 20:05:14 -0500
> Matthew Selsky wrote:
>
> > LibreSSL dropped support for SHA-0 in 2.4.2, and that breaks the
> > build on OpenBSD 6.0
>
> I can only find SHA1 in ntpsec. what am I missing?
H
Yo Matthew!
On Fri, 27 Jan 2017 20:05:14 -0500
Matthew Selsky wrote:
> LibreSSL dropped support for SHA-0 in 2.4.2, and that breaks the
> build on OpenBSD 6.0
I can only find SHA1 in ntpsec. what am I missing?
RGDS
GARY
-
dfoxfra...@gmail.com said:
> Setting aside any countervailing considerations concerning dependencies and
> binary footprint, yes. MAC computation lives in the real-time critical
> section where speed means precision so any optimization we can get here is a
> win.
Just to make sure we are all on
On Fri, Jan 27, 2017 at 03:57:36PM -0500, Daniel Franke wrote:
> On 1/27/17, Eric S. Raymond wrote:
> > Daniel Franke :
> >> Where is this notion coming from that OpenSSL is going to drop MD5 or
> >> SHA1
> >> support any time soon? That's inconceivable to me.
> >
> > I think it was either Achim G
I think what we will do is implement the new "legacy" auth protocol as soon
as Daniel feels comfortable with it, and implement new new secure time
protocol on, again, as soon as Daniel feels comfortable and then delivers
the code.
Dropping support for the legacy legacy MD5 method is not on our roa
How stable is their ID?
How much effort will it be to add it to NTPsec?
My next strawman proposal that we add it NTPsec as soon as convenient, but
make it an option for now.
..m
On Fri, Jan 27, 2017 at 10:40 AM Mark Atwood
wrote:
> Ok, thanks for the update.
>
> ..m
>
> On Fri, Jan 27, 2017 a
If you are deeply concerned with speed, the older (less recommended)
interfaces for MD5 and SHA1 in OpenSSL are faster than the newer EVP
interface. (I don't have the numbers in front of me, but you may want to do
some benchmarking to see if you care.)
https://www.openssl.org/docs/man1.0.1/crypto/
On Fri, Jan 27, 2017 at 03:00:42PM -0800, Hal Murray wrote:
>
> fallenpega...@gmail.com said:
> > How hard would the following be?
> > Just go ahead and add SHA256 to NTPsec then Write an I-D modifying the NTP4
> > protocol documenting it. then Write a patch to NTP classic for it.
> > (yes, I know
fallenpega...@gmail.com said:
> How hard would the following be?
> Just go ahead and add SHA256 to NTPsec then Write an I-D modifying the NTP4
> protocol documenting it. then Write a patch to NTP classic for it.
> (yes, I know, icky code)
I think you are overlooking how long it takes to update t
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
The input side is 2 t
On Fri, Jan 27, 2017 at 03:42:09PM -0500, Eric S. Raymond wrote:
> Daniel Franke :
> > Where is this notion coming from that OpenSSL is going to drop MD5 or SHA1
> > support any time soon? That's inconceivable to me.
>
> I think it was either Achim Gratz or Kurt Roecx (I can't easily search to fin
Daniel Franke :
> I just checked with an OpenSSL dev to make certain: dropping MD5 and
> SHA1 from libcrypto is not even remotely under consideration.
All right. I'm off to Friday night gaming, but given what Mark has said I'm
going to take this as my cue to remove the local copies when I get bac
On 1/27/17, Mark Atwood wrote:
> Daniel, if we make OpenSSL a requirement, can we drop libsodium?
Yes.
> Daniel, which rev of OpenSSL should we require? (Not 0.9.x et al)
1.0.1 and prior are no longer supported upstream so I'm not going to
make any effort to support them either. I don't think
Mark Atwood :
> I like the idea of removing more IPv4 specific code.
>
> If we do, can we still get arrival timestamp from the kernel?
I'm pretty sure the answer is "yes". Checking...it doesn't look like
that code has any dependency on the address family.
> How do standard display functions dis
On 1/27/17, Eric S. Raymond wrote:
> Daniel Franke :
>> Where is this notion coming from that OpenSSL is going to drop MD5 or
>> SHA1
>> support any time soon? That's inconceivable to me.
>
> I think it was either Achim Gratz or Kurt Roecx (I can't easily search to
> find
> out right now). Somebod
I like the idea of removing more IPv4 specific code.
If we do, can we still get arrival timestamp from the kernel?
How do standard display functions display v6 mapped v4 addresses? How do
we want them displayed?
Are there any places left in the code that are storing addresses in
packed-4-octet
Daniel Franke :
> Where is this notion coming from that OpenSSL is going to drop MD5 or SHA1
> support any time soon? That's inconceivable to me.
I think it was either Achim Gratz or Kurt Roecx (I can't easily search to find
out right now). Somebody serious, anyway.
This is not an area in which I
OpenSSL is not going to drop them anytime soon. if/when they do, we can
add back inline support in better understood ways.
Daniel, if we make OpenSSL a requirement, can we drop libsodium?
Daniel, which rev of OpenSSL should we require? (Not 0.9.x et al)
If/when we encounter a target without Op
Where is this notion coming from that OpenSSL is going to drop MD5 or SHA1
support any time soon? That's inconceivable to me.
On Jan 27, 2017 3:21 PM, "Eric S. Raymond" wrote:
> Mark Atwood :
> > We do need to get wacking on the weeds on removing more of this thicket.
>
> Here are our constraint
Mark Atwood :
> We do need to get wacking on the weeds on removing more of this thicket.
Here are our constraints:
* Daniel has stated that he prefers the OpenSSL implementations of MD5 and
SHA-1. He's our crypto expert, so he gets to make that call and I would
have no grounds to even argue w
Yo Eric!
On Fri, 27 Jan 2017 15:01:19 -0500
"Eric S. Raymond" wrote:
> Gary E. Miller :
> > Yes, but NTP does not have to. NTP can just open an IPv6 socket and
> > shove all IPv6 and IPv4 in through that socket. Apache does this,
> > sendmail does this, nginx does this, postfix does this. Ve
Gary E. Miller :
> Yes, but NTP does not have to. NTP can just open an IPv6 socket and
> shove all IPv6 and IPv4 in through that socket. Apache does this,
> sendmail does this, nginx does this, postfix does this. Very standard
> and very easy.
That's interesting. Does this mean we could throw
Yo Eric!
On Fri, 27 Jan 2017 14:42:16 -0500
"Eric S. Raymond" wrote:
> Gary E. Miller :
> > And, don't forget, libisc is still in the tree with its own copies
> > of md5 and sha1. Nuke it!
>
> Er, we can't do tha id we wabt the OpenSSL deoendency to be optional.
So why does openssl need to
Gary E. Miller :
> Yo Mark!
>
> On Fri, 27 Jan 2017 18:17:40 +
> Mark Atwood wrote:
>
> > Can libsodium upstream take a pull request that adds the hash
> > functions that we need?
>
> My understanding is that they considered md5 and sha1 too dangerous to
> use and would not be complicit wit
On Fri, Jan 27, 2017 at 08:38:06PM +0100, Achim Gratz wrote:
> Eric S. Raymond writes:
> > It depends on which MAC algorithms we want to support, a question I've
> > opened
> > in a recent email. It looks like libsodium's support for hash functions in
> > our set is limited to SHA-2, so libsodium
Gary E. Miller :
> And, don't forget, libisc is still in the tree with its own copies of
> md5 and sha1. Nuke it!
Er, we can't do tha id we wabt the OpenSSL deoendency to be optional.
Otherwise, I'd be happy to get rid of that code.
--
http://www.catb.org/~esr/";>Eric S. Raymond
Eric S. Raymond writes:
> It depends on which MAC algorithms we want to support, a question I've opened
> in a recent email. It looks like libsodium's support for hash functions in
> our set is limited to SHA-2, so libsodium can't replace OpenSSL.
SHA1 will go out of OpenSSL sooner than you might
Yo Hal!
On Fri, 27 Jan 2017 01:14:25 -0800
Hal Murray wrote:
> fallenpega...@gmail.com said:
> > I prefer :: tagged IPv6 addresses for IPv4 addresses. No need
> > for a redundant flag.
>
> I don't think that actually works. We need to know if it really is
> an IPv4 address or is an IP
On 1/27/17, Mark Atwood wrote:
> Ah, now I get it. They do support new good stuff, they don't support old
> bad stuff.
>
> Daniel, are you suggesting we want to use OpenSSL instead of inline C of
> md5 and sha1 to take advantage of optimized asm and accellerated
> implementations?
Setting aside
Ah, now I get it. They do support new good stuff, they don't support old
bad stuff.
Daniel, are you suggesting we want to use OpenSSL instead of inline C of
md5 and sha1 to take advantage of optimized asm and accellerated
implementations?
..m
On Fri, Jan 27, 2017 at 10:43 AM Gary E. Miller wro
WolfSSL has a "we are compatible with any OSI approved license" codecil to
their license. I can get a formal signed commitment and document from the
CEO reinforcing it.
We do need to get wacking on the weeds on removing more of this thicket.
..m
On Fri, Jan 27, 2017 at 10:38 AM Gary E. Miller
Yo Mark!
On Fri, 27 Jan 2017 18:17:40 +
Mark Atwood wrote:
> Can libsodium upstream take a pull request that adds the hash
> functions that we need?
My understanding is that they considered md5 and sha1 too dangerous to
use and would not be complicit with anyone doing do.
RGDS
GARY
---
Ok, thanks for the update.
..m
On Fri, Jan 27, 2017 at 10:38 AM Daniel Franke wrote:
> Sharon and Aanchal are already working on a better proposal and have
> an I-D for it. The new MAC function for legacy authentication
> ("legacy" as opposed to NTS) is going to be AES-CMAC.
>
> On 1/27/17, Mar
Sharon and Aanchal are already working on a better proposal and have
an I-D for it. The new MAC function for legacy authentication
("legacy" as opposed to NTS) is going to be AES-CMAC.
On 1/27/17, Mark Atwood wrote:
> How hard would the following be?
>
> Just go ahead and add SHA256 to NTPsec
> t
Yo Mark!
On Fri, 27 Jan 2017 18:14:15 +
Mark Atwood wrote:
> If we are going to have an SSL dependency, I have a pretty strong
> preference towards WolfSSL
It may be the best, but it is not in Gentoo. I suspect few distros have
it. As we see from the libsodium mess, using non standard lib
On 1/27/17, Mark Atwood wrote:
> If we are going to have an SSL dependency, I have a pretty strong
> preference towards WolfSSL
WolfSSL is full GPLv2 with no or-any-lrater-version provision. Are you
comfortable with having a dependency licensed under those terms?
Possibly more importantly, Wolf
How hard would the following be?
Just go ahead and add SHA256 to NTPsec
then
Write an I-D modifying the NTP4 protocol documenting it.
then
Write a patch to NTP classic for it. (yes, I know, icky code)
..m
___
devel mailing list
devel@ntpsec.org
http://
Can libsodium upstream take a pull request that adds the hash functions
that we need?
On Fri, Jan 27, 2017 at 7:40 AM Eric S. Raymond wrote:
> Hal Murray :
> > We currently have 2 and 1/4 crypto packages. That seems like the sort of
> > things you like to clean up.
>
> Yes.
>
> > I would have s
If we are going to have an SSL dependency, I have a pretty strong
preference towards WolfSSL
if we are going to have an OpenSSL dependency, it needs to be to the latest
stable OpenSSL release.
What would be using an SSL library for, that libsodium does not already
provide?
What all are we using
Eric S. Raymond :
> Daniel Franke :
> > If SHA-0 has ever been used in NTP that's news to me. It was broken pretty
> > quickly after publication and never saw much use. Pretty sure any
> > documentation which refers to it is confused.
>
> There were repeated references to "SHA and SHA-1". I don't
Daniel Franke :
> If SHA-0 has ever been used in NTP that's news to me. It was broken pretty
> quickly after publication and never saw much use. Pretty sure any
> documentation which refers to it is confused.
There were repeated references to "SHA and SHA-1". I don't see how that
could reasonablt
Hal Murray :
>
> The current config file parser is 2 passes. The first pass collects the info
> in memory. The second pass does the work. I think that structure is
> leftover from when it could write out the config file, but that was removed a
> long time ago.
>
> If we can't write it out,
If SHA-0 has ever been used in NTP that's news to me. It was broken pretty
quickly after publication and never saw much use. Pretty sure any
documentation which refers to it is confused.
I would prefer that OpenSSL implementations of primitives get used when
available, for performance reasons whic
Hal Murray :
> We currently have 2 and 1/4 crypto packages. That seems like the sort of
> things you like to clean up.
Yes.
> I would have said we have 2 1/2, but somebody deleted half of the 1/2. I
> assume that was part of the --enable-crypto cleanup. There used to be
> routines in libisc
Mark: Heads up! PR issue.
Matthew Selsky :
> On Wed, Jan 25, 2017 at 11:47:01PM -0800, Hal Murray wrote:
> >
> > [From gitlab]
> > > It uses SHA1 but not SHA0 - SHA1 is an option for packet MACs. There
> > > should
> > > be no problem with using the ISC version unconditionally.
>
> https://do
Hal Murray :
>
> [From gitlab]
> > It uses SHA1 but not SHA0 - SHA1 is an option for packet MACs. There should
> > be no problem with using the ISC version unconditionally.
>
> I though I saw something about getting rid of --enable-crypto
It's gone. It actually turned out to be a no-op - I thi
On Thu, Jan 26, 2017 at 01:44:22AM -0800, Hal Murray wrote:
> With configure --enable-leap-smear
> it gets several warnings, then crashes with:
> [104/105] Linking build/main/ntpd/ntpd
> ntpd/ntp_timer.c.3.o: In function `check_leapsec':
> ntp_timer.c:(.text+0x989): undefined reference to `
fallenpega...@gmail.com said:
> I prefer :: tagged IPv6 addresses for IPv4 addresses. No need for a
> redundant flag.
I don't think that actually works. We need to know if it really is an IPv4
address or is an IPv4 address reached via IPv6. Somebody has to switch the
packet between IPv
The current config file parser is 2 passes. The first pass collects the info
in memory. The second pass does the work. I think that structure is
leftover from when it could write out the config file, but that was removed a
long time ago.
If we can't write it out, there is no need for a pars
We currently have 2 and 1/4 crypto packages. That seems like the sort of
things you like to clean up.
I would have said we have 2 1/2, but somebody deleted half of the 1/2. I
assume that was part of the --enable-crypto cleanup. There used to be
routines in libisc for MD5 and SHA1. md5.c is
53 matches
Mail list logo
