proposal: x/crypto/ripemd320: add ripemd320 hashing

[0x-2a]

Summary: Golang has the x/crypto/ripemd160 hashing implementation but not the ripemd320 implementation. Having already done most of the work implementing ripemd320 in Go, I would like to bring it in to x/crypto alongside its smaller counterpart.

Details:

• The differences between ripemd variants are small and fairly simple to implement
• Ripemd 320 and 160 are mostly the same except the 320 variant has a 320 bit output size rather than 160 bit.
• Despite SHA being a better hash, Ripemd can be used in conjunction with SHA256 et al as a double-hashing technique to prevent against length-extension attacks
• Rust recently adopted support for Ripemd320 alongside its 160 and I would like to see the same for golang RIPEMD-320 implementation RustCrypto/hashes#68

[MaxSem]

Note that RIPEMD160 has been deprecated in #30141. RIPEMD320 doesn't add any extra security compared to 160, it just produces a longer hash. If you want something different from the SHA family, wouldn't some modern function like BLAKE2 be better?

[0x-2a]

Oddly I haven't been in this situation before where I'm offering to improve a deprecated feature 😄. Please advise.

The goal of this proposal is to better support ripemd for specific use cases, such as legacy software conversions. Unless users have a specific use case for ripemd, they should choose a better hash. Use cases could be designing for a target hash length over security (e.g. sha and ripemd in bitcoin) or legacy-app conversion (especially php). For whatever reason, Ripemd 160 and 320 were heavily used in the php community, and as users migrate legacy applications they are left looking to reimplement these algorithms on their own. Choosing a better hash isn't always feasible if older hashes are in the data transformation path, and there are many use cases where choosing hash length is more important than how secure it is (e.g. ddos prevention, proof of work, perf optimization).

I'm not familiar with BLAKE2, but I do like that is has support for multiple bit lengths already:

// The blocksize of BLAKE2b in bytes.
BlockSize = 128
// The hash size of BLAKE2b-512 in bytes.
Size = 64
// The hash size of BLAKE2b-384 in bytes.
Size384 = 48
// The hash size of BLAKE2b-256 in bytes.
Size256 = 32

[ALTree]

The fact that the ripemd160 implementation in x/crypto was deprecated (as @MaxSem noted) makes it very unlikely that new code that implements ripemd320 will be accepted into the package, I'm afraid.

The goal of this proposal is to better support ripemd for specific use cases, such as legacy software conversions.

Note that this goal can also be served by putting your ripemd320 implementation in a package outside x/crypto.

cc @FiloSottile for a final decision, but I very much doubt this proposal will be accepted.

[FiloSottile]

Yup, I prefer not to add things to x/crypto that we aren't ready to recommend as the current best modern choice.

It's definitely something that should exist in the ecosystem though! I recommend making it a stand-alone module rather than an x/crypto fork, so it's easy to use as a dependency.

[0x-2a]

I've provided a home for future outdated algos, as there are some more I'd like to translate. Thank you for the feedback.

https://github.com/y3sh/go-legacy-crypto/