Re: [hash2] Question about cryptographic guarantees of hash_append_unordered_range

From: Ivan Matek (libbooze_at_[hidden])
Date: 2024-12-08 20:28:21

On Sun, Dec 8, 2024 at 8:44 PM Peter Dimov via Boost <boost_at_[hidden]>
wrote:

> 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
>