Current status of --enable-crypto

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

I would prefer that OpenSSL implementations of primitives get used when
available, for performance reasons which translate directly to improved
precision.

On Jan 27, 2017 10:20 AM, "Eric S. Raymond" <esr at thyrsus.com> wrote:

> Mark: Heads up!  PR issue.
>
> Matthew Selsky <Matthew.Selsky at twosigma.com>:
> > 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://docs.ntpsec.org/latest/ntpq.html's keytype lists "SHA".  Does
> that mean sha0 or sha1?
>
> From context, SHA-0 - supported only if OpenSSL is linked.  I have
> disambiguated in the documentation.
>
> > OpenSSL/LibreSSL's libcrypto is only needed for ntp.keys that are using
> a digest> that's neither MD5 nor SHA1.
> >
> > As 2 data points (yes, not enough), my users are using MD5
> > internally.  I also spoke to Dr Levine from NIST yesterday and of
> > his 500 customers that use authentication, all but 2 use MD5.  The
> > other 2 customers use SHA1.  None of his customers use anything
> > fancier.
>
> That's kind of interesting. To me it suggests that maybe we should drop
> OpenSSL
> and support for MAC types other than ND5 and SHA-1.  I can see that we
> might
> want to keep the others for PR reasons, though, even if they haven't got
> actual traction.
>
> Mark: do you have an opinion about this?
>
> > Can we make OpenSSL an optional dependency?
>
> Hm.  I thought it was already optional.  But INSTALL says differently, and
> mow I'm not sure.  Checking...
>
> OK, I was right and INSTALL is wrong.  waf has openssl marked optional.
>
> >I'd prefer that we always use the public domain code for MD5 and
> >SHA1 and then use the OpenSSL code when available, but only for
> >digest algorithms that are exclusive to them?  That will allow us to
> >have few #ifdef branches and be better able to test the code. And
> >there's no need to add an extra build requirement when most users
> >won't need it.
>
> I have a higher-priority thing to chew on (nuking interface scanning) but
> I'd take that patch from you.  It's good cleanup even if we then decide to
> drop
> OpenSSL entirely.
> --
>                 <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
> _______________________________________________
> devel mailing list
> devel at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20170127/8dd152c0/attachment.html>