All proposed fixes for a randomized hashing function raise and fall with
a good random number generator to feed the random seed. The seed must be
created very early in the startup phase of the interpreter, preferable
before the basic types are initialized. CPython already have multiple
sources for random data (win32_urandom in Modules/posixmodule.c, urandom
in Lib/os.py, Mersenne twister in Modules/_randommodule.c). However we
can't use them because they are wrapped inside Python modules which
require infrastructure like initialized base types.

Discussion at http://mail.python.org/pipermail/python-dev/2012-January/115263.html

My proposed changes are implemented in my feature fork but not yet well tested. Windows build files needs modification, too.

(for the record, you can use the "create patch" button which creates a reviewable diff)

I disagree with that approach, basically because I disagree that we need a C implementation of MT. Platforms that don't provide /dev/urandom will just have to be less secure. Using the current time (in milliseconds if available) plus the current pid ought to be good enough as a random seed.

We already have a C implementation of MT in Modules/_randommodule.c. I just suggest that we move the implementation to a place, where we can use it as seed.

Why is this listed as a release blocker?  It is questionable whether it should be done at all?  It is a very aggressive change.

Release blocker: I was following the example in #13703. A RNG (PRNG or CSPRNG) is required for randomized hashing function.

The patch contains more than just the RNG changes. Only Include/pyrandom.h, Modules/_randommodule.c, Modules/posixmodule.c, Python/hash.c and parts of Makefile.pre.in are relevant for this tracker item. Sorry for the inconvenience!

On Jan 04, 2012, at 07:30 AM, Raymond Hettinger wrote:

>Why is this listed as a release blocker?  It is questionable whether it
>should be done at all?  It is a very aggressive change.

It's a release blocker so that the issue won't get ignored before the next
release.  That doesn't necessarily mean it must be fixed.

Demoting from release blocker since the hash collision issue got remedied differently.

If this is not needed anymore, please close.

Yes, this ticket can be closed unless there is an interest to include the PRNG in the core.

This is indeed out-of-date.