[Python-Dev] Hash collision security issue (now public)
steve at pearwood.info
Fri Jan 6 11:01:28 CET 2012
Glenn Linderman wrote:
> On 1/5/2012 5:52 PM, Steven D'Aprano wrote:
>> At some point, presuming that there is no speed penalty, the behaviour
>> will surely become not just enabled by default but mandatory. Python
>> has never promised that hashes must be predictable or consistent, so
>> apart from backwards compatibility concerns for old versions, future
>> versions of Python should make it mandatory. Presuming that there is
>> no speed penalty, I'd argue in favour of making it mandatory for 3.3.
>> Why do we need a flag for something that is going to be always on?
> I think the whole paragraph is invalid, because it presumes there is no
> speed penalty. I presume there will be a speed penalty, until
> benchmarking shows otherwise.
There *may* be a speed penalty, but I draw your attention to Paul McMillian's
email on 1st of January:
Empirical testing shows that this unoptimized python
implementation produces ~10% slowdown in the hashing of
~20 character strings.
and Christian Heimes' email on 3rd of January:
The changeset adds the murmur3 hash algorithm with some
minor changes, for example more random seeds. At first I
was worried that murmur might be slower than our old hash
algorithm. But in fact it seems to be faster!
So I think that it's a fairly safe bet that there will be a solution that is
as fast, or at worst, trivially slower, than the current hash function. But of
course, benchmarks will be needed.
More information about the Python-Dev