On Sun, Dec 8, 2024 at 8:44 PM Peter Dimov via Boost
Ivan Matek wrote:
Ideally I'd use 128 or 256 bit integer there, but using __uint128_t portably is still a pain, and hashing unordered containers is a very niche use case. You'd probably never encounter it in practice... well, except for boost::json::object, I suppose.
I fully understand and agree that 99+% of uses will be people just hashing some values inside their process(and use some faster nonsafe hash), never to be exposed outside world or used to sign/verify something... But for me the issues is that in documentation/source this is not mentioned, as I think it is a huge design choice because when it comes to cryptography people(both users and implementers) need to be very paranoid and think of every edge case. So I would suggest that in documentation there is NOT CRYPTOGRAPHICALLY SAFE or this function being called hash_append_unordered_range_noncrypto or hash_append_unordered_range_unsafe or some other name. And then there can be hash_append_unordered_range that actually does combination in cryptographically safe but slow manner. Now I do not know what is proper way to do that, but I presume from your answer that larger accumulator type is secure.
As for int128: my first intuition is that sum type be conditional on size of result_type, i.e. use int128 only when result_type is greater than 64 bits? I am not sure how this affects cryptographic properties of algorithm, but could be good heuristic since IDK of any safe crypto algorithm that uses 64bits or less for result. Still this is not something I would recommend since as mentioned I do not know enough about cryptography to understand what transformations are safe.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost