On Sun, 01 Jan 2012 16:48:32 +0100 Christian Heimes email@example.com wrote:
The talkers claim and have shown that it's too easy to pre-calculate collisions with hashing algorithms similar to DJBX33X / DJBX33A. It might be a good idea to change the hashing algorithm, too. Paul as listed some new algorithms. Ruby 1.9 is using FNV http://isthe.com/chongo/tech/comp/fnv/ which promises to be fast with a good dispersion pattern.
We already seem to be using a FNV-alike, is it just a matter of changing the parameters?
A hashing algorithm without a meet-in-the-middle vulnerability would reduce the pressure on a good and secure seed, too.
We need to fix this as far back as Python 2.6, and it would be nice if a source patch was available that works on Python 2.5 -- personally I do have a need for a 2.5 fix and if nobody creates one I will probably end up backporting the fix from 2.6 to 2.5.
Should the randomization be disabled on 2.5 to 3.2 by default to reduce backward compatibility issues?
Isn't 2.5 already EOL'ed? As for 3.2, I'd say no. I don't know about 2.6 and 2.7.