Bug#1020695: failure to compute digest: md4 and rmd160

Richard B. Kreckel

unread,

Sep 25, 2022, 10:00:05 AM9/25/22

to

Package: openssl
Version: 3.0.5-4

rbk@bitzer:~$ echo foo |openssl dgst -md4
Error setting digest
4087791C597F0000:error:0308010C:digital envelope
routines:inner_evp_generic_fetch:unsupported:../crypto/evp/evp_fetch.c:373:Global
default library context, Algorithm (MD4 : 88), Properties ()
4087791C597F0000:error:03000086:digital envelope
routines:evp_md_init_internal:initialization
error:../crypto/evp/digest.c:252:
rbk@bitzer:~$ echo foo |openssl dgst -rmd160
Error setting digest
40A761FE947F0000:error:0308010C:digital envelope
routines:inner_evp_generic_fetch:unsupported:../crypto/evp/evp_fetch.c:373:Global
default library context, Algorithm (RIPEMD160 : 99), Properties ()
40A761FE947F0000:error:03000086:digital envelope
routines:evp_md_init_internal:initialization
error:../crypto/evp/digest.c:252:

All other digests seem to work fine.

-richy.
--
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

Richard B. Kreckel

unread,

Sep 25, 2022, 5:30:04 PM9/25/22

to

On 9/25/22 21:14, Sebastian Andrzej Siewior wrote:
> See the man page for OSSL_PROVIDER-legacy.

Having to add a the extra option -provider legacy breaks otherwise
flawless existing software.

There are no good reasons to break openssl dgst -rmd160, since RIPEMD160
is a hash algorithm with still good security properties. It is used by a
lot of crypto software (e.g. BitCoin...) Here is how this breaks
Python's HashLib:
$ python
Python 3.10.7 (main, Sep 8 2022, 14:34:29) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import hashlib
>>> h = hashlib.new('ripemd160')
Traceback (most recent call last):
File "/usr/lib/python3.10/hashlib.py", line 160, in __hash_new
return _hashlib.new(name, data, **kwargs)
ValueError: [digital envelope routines] unsupported

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python3.10/hashlib.py", line 166, in __hash_new
return __get_builtin_constructor(name)(data)
File "/usr/lib/python3.10/hashlib.py", line 123, in
__get_builtin_constructor
raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type ripemd160

OpenPGP_signature

Richard B. Kreckel

unread,

Sep 25, 2022, 6:20:03 PM9/25/22

to

W.r.t. RIPEMD160, this seems to be a mistake:
https://github.com/openssl/openssl/issues/16994
Also, Fedora seems to have worked around this.

Sebastian Andrzej Siewior

unread,

Sep 27, 2022, 2:20:04 AM9/27/22

to

On 2022-09-25 22:59:27 [+0200], Richard B. Kreckel wrote:
> On 9/25/22 21:14, Sebastian Andrzej Siewior wrote:
> > See the man page for OSSL_PROVIDER-legacy.
>
> Having to add a the extra option -provider legacy breaks otherwise flawless
> existing software.

This happens. You can add code to the python script to enable legacy
algorithm or replace it with something modern if possible.

> There are no good reasons to break openssl dgst -rmd160, since RIPEMD160 is
> a hash algorithm with still good security properties. It is used by a lot of
> crypto software (e.g. BitCoin...) Here is how this breaks Python's HashLib:

Yes and I've been looking and haven't found anything other than BitCoin
that is kind of prominent. It is not part of any standard.

> -richy.

Sebastian

Sebastian Andrzej Siewior

unread,

Sep 27, 2022, 2:30:04 AM9/27/22

to

The issue is not closed by OpenSSL upstream so there is nothing that I
can backport. I don't want to move ripemd160 from legacy to the normal
suite becauase I don't want to divert from upstream. This situation
isn't unique to Debian and others are affeected, too.

Sebastian

Richard B. Kreckel

unread,

Sep 29, 2022, 2:10:04 PM9/29/22

to

On 9/27/22 08:15, Sebastian Andrzej Siewior wrote:
> It is not part of any standard.

It could hardly be less standardized. See ISO/IEC 10118-3:2018.

Sebastian Andrzej Siewior

unread,

Sep 29, 2022, 3:30:03 PM9/29/22

to

On 2022-09-29 20:03:56 [+0200], Richard B. Kreckel wrote:
> On 9/27/22 08:15, Sebastian Andrzej Siewior wrote:
> > It is not part of any standard.
>
> It could hardly be less standardized. See ISO/IEC 10118-3:2018.

That is not what I meant.
Wahat I meant that it is part of a standard/ specification like TLS then
it would be used as part of that. Or as part of the CA/Browser Forum so
that it would be used in X.509 certificate that is issued and validated.
While looking I only found that it is used as part of the Bitcoin
protocol.

> -richy.

Sebastian

Richard B. Kreckel

unread,

Nov 29, 2022, 5:20:04 PM11/29/22

to

IMO, this bug can be closed. There's been the decision by the OpenSSL
Managment Board to reinstate RIPEMD160 (and only that) to the default
providers in release 3.0.7.

The other algorithm, MD4 is unsafe and remains in the legacy provider.

References:
OMC decision:
<https://www.openssl.org/blog/blog/2022/10/18/rmd160-and-the-legacy-provider/>
ChangeLog: <https://www.openssl.org/news/cl30.txt>

-richy.