With the release of OpenSSL 3.0 and the new provider architecture, some algorithms that were considered legacy by the OpenSSL team at the time were moved to the legacy provider, to be loaded optionally by those wishing to still use any of said algorithms.

Our main criteria for moving an algorithm to the legacy provider were that the algorithm was too weak and not recommended for use in security applications, or that the algorithm had commonly fallen out of favour in preference to newer and potentially better algorithms.

Among the algorithms that were moved to the legacy provider was RIPEMD160 (also known as RMD160). At the time, we were under the impression that it was little used.

We were wrong. RIPEMD160 is used with bitcoin, which makes for a huge user base, and while one might argue that all that’s needed is to explicitly load the legacy provider – potentially by configuration–, it turns out to be difficult in ecosystems with multiple dependencies where OpenSSL is an embedded component under other layers of libraries, further exasperated for those who do not have the possibility to modify the OpenSSL configuration, or use their own.

Last week, the OMC voted in favour of an exception to the criteria for what’s normally accepted in a release branch, and to thereby accept PR#19375 – which makes RIPEMD160 available in the default provider as well as the legacy provider – into the next update of OpenSSL 3.0, subject to normal review processes.