Re: [hash2] Question about cryptographic guarantees of hash_append_unordered_range

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2024-12-08 21:29:21

El 08/12/2024 a las 21:32, Peter Dimov via Boost escribió:
> Ion Gaztañaga wrote:
>> El 08/12/2024 a las 21:04, Ion Gaztañaga via Boost escribió:
>>> El 08/12/2024 a las 20:49, Vinnie Falco via Boost escribió:
>>>> On Sun, Dec 8, 2024 at 11:44 AM Peter Dimov via Boost
>>>> <boost_at_[hidden]>
>>>> wrote:
>>>>
>>>>> Matt Borland is considering proposing boost::uint128_t to Core, but
>>>>> that would mean depending on Core.
>>>>>
>>>>
>>>> Would it be better to make this its own library? More fine-grained
>>>> libraries could have appeal to Boost users.
>>>
>>> I wouldn't like to add another dependency to the library users.
>>>
>>> Wouldn't be acceptable to take all the bits from the hash, treat the
>>> hash as an array 64 bit or 32 bits hashes and apply something like
>>> hash_combine or similar to each element so that we combine big hashes
>>> preserving all bits from result_type?
>>>
>>> This would also scale to 512 bit or bigger hashes.
>>
>> Auto-replying...
>>
>> Just realized that the operation must be commutative so hash_combine would
>> not work. Maybe just adding those individual hashes could do the trick.
> 
> I suppose I can just add the individual uint64_t[] values without carry, instead of
> emulating a full-featured uint128_t or uint256_t.

Yeah, that was the idea. If, for some reason, this operation is slow, 
maybe on some platforms it can be improved using SIMD.

Ion