[issue13703] Hash collision security issue

[Antoine Pitrou]

Antoine Pitrou <pitrou at free.fr> added the comment:

> Jim Jewett <jimjjewett at gmail.com> added the comment:
> 
> On Wed, Jan 25, 2012 at 1:05 PM,  Antoine Pitrou <pitrou at free.fr>
> added the comment:
> 
> > It looks like that approach will break any non-builtin type (in either C
> > or Python) which can compare equal to bytes or str objects. If that's
> > the case, then I think the likelihood of acceptance is close to zero.
> 
> (1)  Isn't that true of *any* patch that changes hashing?  (Thus the
> PYTHONHASHSEED=0 escape hatch.)

If a third-party type wants to compare equal to bytes or str objects,
its __hash__ method will usually end up calling hash() on the equivalent
bytes/str object. That's especially true for Python types (I don't think
anyone wants to re-implement a slow str-alike hash in pure Python).

> (2)  I think it would still work for the lookdict_string (or
> lookdict_unicode) case ... which is the normal case, and also where
> most vulnerabilities should appear.

It would probably still work indeed.

> (3)  If the alternate hash is needed for non-string keys, there is no
> perfect resolution, but I suppose you could get closer with
> 
>     if obj == str(obj):
>         newhash=hash(str(obj))

That may be slowing down things quite a bit. It looks correct though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13703>
_______________________________________