Re: Hash Collisions with PERL_HASH

Why would a sysadmin have set PERL_HASH_SEED=0?

Anyway, rather than brute-forcing, a real attack would use the known hash seed and the known hash algorithm, and with those known factors it's fairly trivial to offline generate a set of short strings which all map to the same hash bucket slot (but not necessarily to the same hash value, which has more bits than the number of buckets).

But no, I'm not going to explain how.

Dave.

Comment on Re: Hash Collisions with PERL_HASH_SEED=0

Replies are listed 'Best First'.
Re^2: Hash Collisions with PERL_HASH_SEED=0 by ikegami (Patriarch) on Apr 06, 2018 at 16:17 UTC
When `PERL_HASH_SEED=0` isn't used, each hash is given its own random seed at creation, and it switches to a new random seed when Perl detects a degenerate hash. So, those "known factors" can't be known without `PERL_HASH_SEED=0`.	[reply] [d/l] [select]
Re^2: Hash Collisions with PERL_HASH_SEED=0 by jimpudar (Pilgrim) on Apr 06, 2018 at 16:12 UTC
Hi, Dave, Thanks for the reply - that was very clear. I don't think any sysadmin would actually have PERL_HASH_SEED=0, I was just curious after reading that bit of info in perlsec. Looks like I'll be spending some time learning about how hash tables are implemented! Thanks again, Jim	[reply]