boostorg/container_hash
1
0
Fork 1
mirror of https://github.com/boostorg/container_hash.git synced 2025-08-04 15:04:39 +02:00
Code Issues Packages Projects Releases Wiki Activity

Update notes.adoc

Browse Source
This commit is contained in:
Peter Dimov
2023-03-02 19:45:18 +02:00
parent 7c49f0bfb1
commit 5638134081
1 changed files with 3 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
doc/hash/notes.adoc
View File

@@ -200,16 +200,9 @@ In Boost 1.81, `hash_range` was changed to process elements of type `char`,
A `uint32_t` is composed from `first[0]` to `first[3]`, and that `uint32_t` A `uint32_t` is composed from `first[0]` to `first[3]`, and that `uint32_t`
is fed to `hash_combine`. is fed to `hash_combine`.
In principle, when `size_t` is 64 bit, we could have used `uint64_t` instead. In Boost 1.82, `hash_range` for these types was changed to use
We do not, because this allows producing an arbitrary hash value by choosing https://github.com/pdimov/mulxp_hash[`mulxp1_hash`]. This improves both
the input bytes appropriately (because `hash_combine` is reversible.) quality and speed of string hashing.
Allowing control only over 32 bits of the full 64 bit `size_t` value makes
these "chosen plaintext attacks" harder.
This is not as harmful to performance as it first appears, because the
input to `hash<string>` (e.g. the key in an unordered container) is often
short (9 to 13 bytes in some typical scenarios.)
Note that `hash_range` has also traditionally guaranteed that the same element Note that `hash_range` has also traditionally guaranteed that the same element
sequence yields the same hash value regardless of the iterator type. This sequence yields the same hash value regardless of the iterator type. This