Add ripemd definitions #175
Conversation
|
Note that there are multiple precedents for "non-FIPS" hash functions to live outside of the single-byte space, the most notable example being Is burning |
|
I'm kind of with @ribasushi on this and would rather keep them together as a family - it certainly makes it easier to look them up - but that does somewhat contradict the previous ask in #117. What would be the justification for using one-byte for 160? Is there a common usage that we'd expect this to attract that would benefit from shortest-possible representation? Even in Bitcoin I think the only usage is over the top of a sha2-256 as well, a combination that might warrant its own entry in here (in the same fashion as dbl-sha2-256) if they were to be put into common usage. Also there's the 0xbX block that's got plenty of holes if we're looking for an arbitrary spot in the one-byte range, |
|
These days we try to put as little as possible in the <0x80 range. Some things in there are due to historic reasons and wouldn't likely end up there today. So I suggest moving the ripemd-160 also to the same range as the others. |
|
ripemd-160 has been moved to the two byte range and is contiguous with other ripemd sizes. |
There was a problem hiding this comment.
I'll wait 48h for any objections from @Stebalien, if not, I'll merge it.
As proposed in #117, there are no definitions for the ripemd family of hashes.
The previous PR would have been sufficient with the given feedback, but the author never made the requested changes and the PR is now over a year old.
This PR would replace #117.
It conforms to feedback on #117, with the more common ripemd-160 hash using the one byte space and the less common algorithms using the two byte space.
0x52 was chosen somewhat arbitrarily as the ASCII encoding of 'R'.
Furthermore, 0x51 is the serialization code for CBOR, which means 0x52 is unlikely to be needed as a value in relation to CBOR.