On 2 Dec 2014 at 20:27, Stephan T. Lavavej wrote:
[Niall Douglas]
BTW I think MSVC/Dinkumware *has* fixed their std::hash<>, theirs is several orders of magntitude more complex than the trivial hash libstdc++ uses. Indeed this leads to MSVC's apparent poor unordered_map performance when compared to GCC (about a 12-40% performance loss). Stephan can probably confirm or refute this claim of MSVC/Dinkumware having a safe hash though. It may just be he uses a well distributed hash instead of a trivial hash, not one cryptographically safe.
VC currently uses FNV-1a for everything. This is good at jumbling up bits, and pretty fast (although not as fast as returning an integer unchanged), but it is absolutely not cryptographically secure, nor does it attempt to resist collisions triggered by an intelligent adversary.
We reserve the right to change our hash implementation in the future.
Thanks for the confirm Stephan. Out of curiosity I went and looked up what Python did to solve this (here's the discussion: http://bugs.python.org/issue13703). In the end, they simply XOR salted the hash with a cryptographically generated random number produced at process launch (source: https://docs.python.org/3/reference/datamodel.html#object.__hash__) and carried on with their previous algorithm. I think std::hash could be similarly adjusted with ease, the hard part is generating a cryptographically secure random number. I don't believe C++ 11 even has such a secure generator in <random> even ... nevertheless, the C++1z standard might consider adding a static function to the STL which sets the std::hash salt value to something. It might be an idea to only permit that function to be called exactly once. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/