[Python-Dev] Hashes in Python3.5 for tuples and frozensets (original) (raw)

Anthony Flury anthony.flury at btinternet.com
Wed May 16 17:48:27 EDT 2018

This may be known but I wanted to ask this esteemed body first.

I understand that from Python3.3 there was a security fix to ensure that different python processes would generate different hash value for the same input - to prevent denial of service based on crafted hash conflicts.

I opened two python REPLs on my Linux 64bit PC and did the following

Terminal 1:

 >>> hash('Hello World')
-1010252950208276719

 >>> hash( frozenset({1,9}) )
  -7625378979602737914
 >>> hash(frozenset({300,301}))
-8571255922896611313

 >>> hash((1,9))
3713081631926832981
 >>> hash((875,932))
3712694086932196356

Terminal 2:

 >>> hash('Hello World')
-8267767374510285039

 >>> hash( frozenset({1,9}) )
  -7625378979602737914
 >>> hash(frozenset({300,301}))
-8571255922896611313

 >>> hash((1,9))
3713081631926832981
 >>> hash((875,932))
3712694086932196356

As can be seen - taking a hash of a string does indeed create a different value between the two processes (as expected).

However the frozen set hash, the same in both cases, as is the hash of the tuples - suggesting that the vulnerability resolved in Python 3.3 wasn't resolved across all potentially hashable values. lI even used different large numbers to ensure that the integers weren't being interned.

I can imagine that frozensets aren't used frequently as hash keys - but I would think that tuples are regularly used. Since that their hashes are not salted does the vulnerability still exist in some form ?.

--

Anthony Flury email : Anthony.flury at btinternet.com Twitter : @TonyFlury <https://twitter.com/TonyFlury/>

More information about the Python-Dev mailing list