We should only be using widely vetted algorithms, IMHO. We really don't
actually need more than sha256, but if we're going have a second hash
and to replace rmd160, I'd recommend using SHA-3 (which is Keccak based
and uses a quite different construction than SHA-2, and is a national
standard.) Failing that, I'd suggest BLAKE2 or BLAKE3, which are based
on very heavily studied primitives.
In no case should a hash as short as 128 bits be used; birthday attacks
on such hashes are feasible.
Perry
On 11/9/21 15:33, Vadim-Valdis Yudaev wrote:
Hi Chris,
What about the SHAKE algorithm? We could choose shake-128 to replace rmd160.
It's a new and fast hash function. Anyway, I'm just suggesting.
Vadim-Valdis
On Nov 9, 2021, at 21:28, Chris Jones <[email protected]> wrote:
Hi,
One thing that became apparent with the recent migration to openssl 3 is that
rmd160 has been declared obsolete. Openssl3 has done this, and moved this
algorithm to its ‘legacy’ set of providers, such that by default it is not
available.
I ‘fixed’ this in the openssl3 port with
https://github.com/macports/macports-ports/commit/df5e1c619a6d1884ccf234d4e652d2303af09e35
But I am thinking the fact this is required should be taken as an indication
that we should review our use of rmd160 in macports, in preparation for some
future OS where it is no longer available. I am not imagining this will likely
be ‘soon’, but I think its probably better we start planing for it sooner
rather than later.
We use rmd160 in a few places in macports. A possibly incomplete list is
1. Its one of the default checksums we provide in portfiles to validate source
tarballs.
2. Its the checksum we provide alongside out binary tarballs
I don’t think either of those is hard to ‘fix’. I.e. for 1. We could (should?)
start recommending a different checksum to replace the rmd160 one we use. For
2., we could start publishing a second more modern checksum along side the
rmd160 one, and then have base use this if present and fallback to rmd160 if
missing.
Thoughts ?
Chris
