btw, Tim&#39;s commit message on this one is amusingly relevant. :)<div><br></div><div> <a href="http://hg.python.org/cpython/diff/8d2bbbbf2cb9/Objects/dictobject.c">http://hg.python.org/cpython/diff/8d2bbbbf2cb9/Objects/dictobject.c</a></div>

<div><br><br><div class="gmail_quote">On Fri, Jan 13, 2012 at 6:25 PM, Gregory P. Smith <span dir="ltr">&lt;<a href="mailto:greg@krypto.org">greg@krypto.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#330033"><br>
    Clearly these ideas are more complex than adding randomization, but
    adding randomization doesn&#39;t seem to be produce immunity from
    attack, when data about the randomness is leaked.<br>
  </div>

</blockquote></div><br></div><div>Which will not normally happen.</div><div><br></div><div>I&#39;m firmly in the camp that believes the random seed can be probed and determined by creatively injecting values and measuring timing of things.  But doing that is difficult and time and bandwidth intensive so the per process random hash seed is good enough.</div>


<div><br></div><div>There&#39;s another elephant in the room here, if you want to avoid this attack use a 64-bit Python build as it uses 64-bit hash values that are significantly more difficult to force a collision on.</div>

<span class="HOEnZb"><font color="#888888">
<div><br></div><div>-gps</div>
</font></span></blockquote></div><br></div>