But, the point of using a hash table is really to get the very best best- and average- case behavior. So, what's the point now?
-
-
Replying to @BRIAN_____
the defenses in place also protect against accidentally bumbling into the worst case, as was the case for the Rust issue.
1 reply 0 retweets 0 likes -
Replying to @Gankro
If you clone a HashMap then will both HashMaps have equivalent RandomState? Why wasn't Clone impl modified too?
2 replies 0 retweets 0 likes -
Replying to @BRIAN_____ @Gankro
There's a custom clone impl for RawTable so cloning an HM probably creates a fresh map with new random state.
2 replies 0 retweets 0 likes -
Replying to @ManishEarth @Gankro
pub struct HashMap<…> { // […] prevent hash collision attacks. hash_state: S, table: RawTable<K, V>, … }
1 reply 0 retweets 0 likes -
Also, I wonder if there are any considerations regarding caching seed in thread-local storage w.r.t. fork()/clone().
1 reply 0 retweets 0 likes -
New attack?: 1. Insert N elems 2. Iterate; save iteration order 3. Remove all 2. Re-insert all in same HT in same order
1 reply 0 retweets 0 likes -
Compare to this prior to "fix": 1. Insert N elems into a HT. 2. Force copy of those elems into a new HT. Both O(n**2)?
1 reply 0 retweets 0 likes -
Replying to @BRIAN_____ @ManishEarth
this doesn't work because we don't shrink; the "attack" is reliant on having a lower cap table.
1 reply 0 retweets 0 likes -
so basically you also need to get a shrink_to_fit in there.
2 replies 0 retweets 0 likes
OK, but that doesn't change the validity of attack. Users of moderately-large hash tables are likely to shrink.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.