Subject: Re: [boost] What hash functions should be included in a hypothetical Boost hash-v2 library?
From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2017-12-31 16:05:49
On Sun, Dec 31, 2017 at 7:22 AM, James E. King, III via Boost
> On Sat, Dec 30, 2017 at 7:28 PM, Peter Dimov via Boost <
>> What (non-cryptographic) hash functions should a hypothetical future Boost
>> hash library contain? Have clear winners emerged by now? Which ones do
>> people prefer?
Each hash function has its own strengths and weaknesses. Some are
optimized for 64-bit or have specific 64-bit implementations. Others
work well for small keys. Some work well for fixed size keys, or work
better with aligned data. These are popular:
The design of xxhash allows cost-free initialization of the hash
function with a random salt to prevent algorithmic complexity attacks.
Whether or not a hash function can be hardened in this fashion is also
a distinguishing characteristic that should be documented and provided
as an option.
For hash functions which don't support a built-in salt it is trivial
to write a wrapper which first hashes a generated value and then
hashes the rest of the user defined data, this wrapper would work with
any Hasher at the expense of some performance.
> We already have MD5 and SHA1 in Boost.Uuid.
Those are cryptographic hash functions. We need to be careful with
exposing interfaces which claim to do cryptographic hashing, because
the results of cryptographic hashing are usually desired to be
portable (same on all machines) and use a particular serialization
method. A hashing framework for use with unordered containers usually
does not allow the user to define the format of serialized objects
(nor should it).
On Sun, Dec 31, 2017 at 7:21 AM, Andrey Semashev via Boost
> I often use MurmurHash
Murmur is vulnerable to algorithmic complexity attacks:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk