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: * xxhash * spooky * fnv 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: http://emboss.github.io/blog/2012/12/14/breaking-murmur-hash-flooding-dos-re... Thanks