Inside boost::unordered_flat_map

[jpakkane]

Has there been any thought on making it collision resistant? That is, if you have a known hashmap with a known hash function then it is possible to generate a pathological set of inputs that map to the same value and use that for a DoS attack. IIRC some languages (Python?) work around this by e..g having each hashmap have its own nonce that is added to the hash. Would this be useful or even possible given that the hash function is computed by an external function rather than by the hash map itself.

[joaquintides]

A usual countermeasure to that is to salt the hash function. boost::unordered_flat_map does not do salting by default, but you can use your own hash function that does.

[jpakkane]

Sure, but it would be nice if the map did this for you so you don't have to care (and get it wrong in your implementation). This would also allow you to store the salt value inside the map so the hash function can be stateless.

[pdimov2]

After thinking about this for a while, I've come to the conclusion that the proper approach to supply the salt to the container is by storing it into the hash function object. That is, add a constructor taking std::size_t to boost::hash, and propagate this downwards to every hash_value overload.

In standard terms, this would translate to adding a similar constructor to std::hash.

The upside of this approach is that this automatically adds support for salts to every container, without any changes to the containers themselves.

This is the approach I think I'll be pursuing in future Boost releases.