[Python-Dev] Hashes in Python3.5 for tuples and frozensets

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