Samuel Neves wrote:
Additionally, one of the constructors for keying is std::uint64_t. While this is mostly OK for the hash table DoS-prevention use case, it is woefully small for cryptographic purposes. This constructor should not exist in this case.
While it's trivially true that uint64_t is not enough seed for cryptographic purposes, MD5 seeded with an unknown uint64_t seed is still incrementally much more cryptographic than plain MD5. The use case here is generic code. The user has something templated on the hash algorithm that is currently using e.g. xxhash_64 seeded with uint64_t. But this turns out to not work well in practice because collisions happen. So they just change the template parameter from xxhash_64 to md5_128 and carry on. For real crypto, you'd have the code using HMAC-SHA2-256, and while hmac_sha2_256 doesn't much need the uint64_t constructor, I very much doubt that anyone would use it by mistake. The rationale for adding a byte seed constructor to everything, even though the functions aren't necessarily designed for it, is the same; a hash function seeded with something unknown to the attacker is incrementally much more secure than the same hash function not seeded with anything.