-
Notifications
You must be signed in to change notification settings - Fork 185
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unsafe with attacker controlled keys #17
Comments
It may be considered as good behavior - in case of attack it just "explodes" and probably OS will terminate it for using too much RAM. Alternative attack will carefully select keys so they all are hashed to the same bin. If you really need to protect from DDoS attacks, you should use hash functions specifically designed for DDoS mitigation. Look at siphash. Or you can use just SHA2, but it will be slower. |
// assume STL has a crappy hash function
struct hasher { size_t operator()(const size_t& _Keyval) const { return _Keyval; } }; I have bad news, this is exactly the case on Linux. Which triggered an out of memory crash just by using |
As far as I can tell, boost has this same exact behaviour as well: template <> struct basic_numbers<int> :
boost::hash_detail::enable_hash_value {}; template <typename T>
typename boost::hash_detail::basic_numbers<T>::type hash_value(T v)
{
return static_cast<std::size_t>(v);
} |
This seems easy to fix. Permute the hashes against a per-table constant. Every time you rehash you change the constant, but if the load ratio doesn't demand it then just rehash without growing the table, right? |
It's possible to trigger explosive memory usage, when carefully picking keys, which causes the hash table to grow for every insertion eventually resulting in an out of memory condition.
Pseudo code:
The text was updated successfully, but these errors were encountered: