When I compute SHA1 and SHA256 via *_mb.h functions in v2.24.0, hashes are generated as uint32_t arrays, so bytes need to be rearranged to yield a normal byte-ordered digest. However, MD5 is computed as a normal byte-ordered digest right away, which creates challenges for a generic wrapper for multi-buffer hashing functionality because there is no way to tell which hash type produces which byte order.
For example, hashing ABC yields these bytes sequences on an x64 Intel processor.
SHA1: 3c01bdbb26f358bab27f267924aa2c9a03fcfdb8
bytes: bb bd 01 3c ba 58 f3 26 79 26 7f b2 9a 2c aa 24 b8 fd fc 03
uint32_t[]: 3c01bdbb 26f358ba b27f2679 24aa2c9a 03fcfdb8
The byte order conversion is easy enough and documenting it for different types of hashes and processor architectures could be the solution for this issue, but having either consistent order or some indicator returned to indicate byte order would be more self-contained.
When I compute SHA1 and SHA256 via
*_mb.hfunctions in v2.24.0, hashes are generated asuint32_tarrays, so bytes need to be rearranged to yield a normal byte-ordered digest. However, MD5 is computed as a normal byte-ordered digest right away, which creates challenges for a generic wrapper for multi-buffer hashing functionality because there is no way to tell which hash type produces which byte order.For example, hashing
ABCyields these bytes sequences on an x64 Intel processor.SHA1: 3c01bdbb26f358bab27f267924aa2c9a03fcfdb8
SHA256: b5d4045c3f466fa91fe2cc6abe79232a1a57cdf104f7a26e716e0a1e2789df78
MD5: 902fbdd2b1df0c4f70b4a5d23525e932
The byte order conversion is easy enough and documenting it for different types of hashes and processor architectures could be the solution for this issue, but having either consistent order or some indicator returned to indicate byte order would be more self-contained.