Current status of --enable-crypto

[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://docs.ntpsec.org/latest/ntpq.html's keytype lists "SHA".  Does that mean sha0 or sha1?

> I though I saw something about getting rid of --enable-crypto
> 
> We currently require libsodium.  Do we require libssl?  If so, we can drop 
> the ISC crypto code.
> 
> Does libsodium include SHA1 and friends?  Do we still need libssl?

We bundle a public domain implementation of MD5 and SHA1 (in the ISC code).

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.

Can we make OpenSSL an optional dependency?  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.


Thanks,
-Matt