Why does Data.HashTable use salt hashing (from Data.Hashable)?

Question

I do not understand why Data.HashTable uses Data.Hashable , which has hashWithSalt as a method (only / main).

This does not correspond to the natural optimization of computing the hash value once and stores it in the object (naturally, because Haskell objects are immutable).

If I want to use HashTables with this, then I am forced to implement hashWithSalt . (Going 1.2.0. * To 1.2.1. *, Hashable has reintroduced hash as a class method, but does this not help?)

Actual implementations of the table do not seem to be used by hashWithSalt ( HashTable.ST.Linear does not exist at all, HashTable.ST.Cuckoo uses only two fixed salts).

Answer 1

As Carl points out in the comments, switching to the hashWithSalt method only with hash (as the original Hashable ) was supposed to allow people to mitigate DOS attacks based on hash collisions. Over a period of time, each individual run generated a different random default salt, using unsafePerformIO in the background. This lack of reproducibility turned out to be a huge problem, however, for people interested in, for example, keeping data structures in different series, getting reliable benchmarking numbers, etc.

So, the current approach is to provide this method, but it is usually deferred to a fixed salt by default, and then adds a warning to the documentation that it remains susceptible to various potential DOS attack vectors if used publicly -. (You can see for yourself in the documentation: http://hackage.haskell.org/package/hashable-1.2.1.0/docs/Data-Hashable.html )

Since hash is the class’s own method, it’s simple enough to implement an object with a “modeless” hash that is marked with it, and in addition, you can implement hashWithSalt as soon as xor ing with salt, if you want. Or, as comments note, you can implement hashWithSalt using the more legitimate hash method of the generated / memoed hash .