Current status of --enable-crypto

[Achim Gratz]

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 disabled by default. I hope to be able to disable TLS 1.0 by
> default in a few years. At that time it _might_ be possible to
> have an option to disable MD5 and SHA-1, but it would require
> someone to actually put an effort into that. And some people might
> actually want to have such an option, so maybe someone will.

That's about the timeline I had in mind when I said "sooner than you
might wish".  Plus, unforeseen events may accelerate that timeline,
however unlikely that may seem today.  For example, SHA1 got removed
from SSL certificates both slower than some folks argued for and faster
than some other folks hoped for.

> But even then it seems unlikely that they get disabled by default
> the first 5 years. If you only care about the preimage resistance,
> they are still fine. There are also just too many applications that
> would get broken by disabling it.

My point was (and I should have been more clear about it) that NTP uses
these two hashes for different purposes and with a different
justification than OpenSSL, so relying on this or any other library to
keep carrying it while their genuine use cases within these libraries
peter out is setting up for an avoidable point of failure.  The current
consensus on that risk assessment seems to be that NTP probably stops
using MD5 and SHA1 before OpenSSL drops it from their library and the
plan B is that it can still pull in the code into NTP should the drop
happen earlier.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra