First of all I am too lazy to actually test whether changing the initial value changes the relative choices of hash buckets. I strongly suspect it does, but I either have to work it out by hand or else install a bunch of stuff on this computer (eg Perl) and then write a program. What we really want to do is tell that it sends what had been 0 buckets back to 0, and for that I should find those strings which means installing stuff, which I haven't done...
in reply to Re: Hash Clash on purpose
in thread Hash Clash on purpose
However assuming that the analysis shows that changing the initialization value does change hashing decisions, your pseudo-code looks wrong to me. You are initializing it randomly per hash lookup. For hashing to work, the hash lookup algorithm has to be consistent from lookup to lookup. Instead what you need to do is save the value of the initial value somewhere and then pull that into hash_PeRlHaSh.
That means that you have to store that somewhere. Several options exist. One is to reserve space per hash to store its initialization value, and then look that up per lookup. Another is to have a global value chosen for all of your hashes. And a third is to make it a random compile-time constant. Problems with binary linking of XS modules that have been copied from point A to B make the last one infeasible. The first one adds 4 bytes to every hash, which isn't that much, but we have a lot of small hashes. An offhand guess is that we would see 1-5% space usage increase, and (of course) binary incompatibility.
The middle option (a run-time random constant) looks to be the best bet. p5p might have some arguments over binary compatibility (code compiled with hash lookups initialized to 0 won't match code compiled with your new initialization) but it should be easy to have whether to initialize randomly or to 0 at startup to be a compile-time flag.
Hmmm...looks like I argued myself into believing that you can fix the problem with your approach. It would be worthwhile for you to try to make the fix, run tests to verify that it does make the performance attack infeasible, then try to get it accepted... :-)