4 ms·
Why was Rust's hashmap only tested with SipHash? It's known to be pretty bad for performance. I'm biased as the author of course, but try adding a benchmark wi
by orlp 2y ago
Why was Rust's hashmap only tested with SipHash? It's known to be pretty bad for performance.
I'm biased as the author of course, but try adding a benchmark with the Rust hasher + foldhash as well: https://github.com/orlp/foldhash https://github.com/orlp/foldhash.
- espadrine 2y agoThey are looking for a data structure that is robust against hash flooding attacks like https://www.cve.org/CVERecord?id=CVE-2011-4815 https://www.cve.org/CVERecord?id=CVE-2011-4815 You mention that foldhash does not claim to provide HashDoS resistance against interactive attackers, so perhaps that disqualifies it. If anything, given this requirement, comparing with wyhash, as they do in the article, is misleading.
- vlovich123 2y agoXxh3 would have this property and would be drastically faster. Siphash is just a bad default choice imho.
- orlp 2y agoXXH3 does not have this property, no more than foldhash does.
- orlp 2y ago> You mention that foldhash does not claim to provide HashDoS resistance against interactive attackers, so perhaps that disqualifies it. The linked CVE is not an interactive attack either FYI, so foldhash would be sufficient to protect against that. When I say an "interactive attacker" I mean one that analyzes hash outcomes (either directly or indirectly through things like timing attacks and iteration order) to try and reverse engineer the hidden internal state. > If anything, given this requirement, comparing with wyhash, as they do in the article, is misleading. That is correct. There is no reason to believe wyhash is secure against interactive attackers.