A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://mail.python.org/pipermail/python-dev/2011-December/115136.html below:

[Python-Dev] Hash collision security issue (now public)

[Python-Dev] Hash collision security issue (now public) [Python-Dev] Hash collision security issue (now public)Antoine Pitrou solipsis at pitrou.net
Thu Dec 29 14:21:19 CET 2011
On Thu, 29 Dec 2011 13:57:07 +0100
Armin Ronacher <armin.ronacher at active-4.com> wrote:
> 
> - Option c: Random salt at runtime
>   + Easy to implement
>   - impossible to synchronize
>   - breaks unittests in the same way as a compiled in salt would do

This option would have my preference. I don't think hash() was ever
meant to be "synchronizable". Already using a 32-bit Python will give
you different results from a 64-bit Python.

As for breaking unittests, these tests were broken in the first place.
hash() does change from time to time.

> Where to add the salt to?  Unicode strings and bytestrings (byte
> objects) I guess since those are the most common offenders.  Sometimes
> tuples are keys of dictionaries but in that case a contributing factor
> to the hash is the string in the tuple anyways.

Or it could be a process-wide constant for all dicts. If the constant
is additive as proposed by Mark the impact should be negligible.
(but the randomness must be good enough)

Regards

Antoine.


More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4