On 2016-06-07 19:46, Larry Hastings wrote:
> 
> Larry Hastings added the comment:
> 
> Thank you for summarizing the debate. It made it a lot easier to 
> 
>> * blocking initialization of the hash secret. This occurs regardless of script contents; at present Python simply can't be used at all in low-entropy situations. I feel that this issue is a release blocker.
>>
>> Possible resolutions:
>>   * accept possible low-entropy initialization of the hash secret; using the patches supplied here by myself and Victor.
>>   * add a command-line flag to disable "strong" initialization of the hash secret (or revive the old -R flag).
>>   * simply require user-space workarounds like setting PYTHONHASHSEED
> 
> The latter two approaches are unacceptable IMO.  They result in a poor user experience.  Python should do the "right" thing by default; the "right" thing includes not taking 90 seconds to start up.
> 
> By process of elimination, this leaves only the first approach as viable.  Ergo, let's do that.
> 
> The hash secret is a 32-bit integer, even on 64-bit builds of Python.  It is not and cannot be cryptographically secure.  It's frankly ridiculous to fret about "strong" initialization of it at the cost of a 90 second startup time.
> 
> (For posterity: when people mention "SipHash", they're talking about the hashing algorithm used for str/dict/etc.  The seed for SipHash is the "hash secret" we're talking about here.)

The secret for SipHash is composed of two 64bit integers. The entire
_Py_HashSecret_t struct is 24 bytes. The remaining 8 bytes are used for
XML hash randomization of libexpat. Only the manual seed with
PYTHONHASHSEED is a 32bit integer which is stretched to 24 bytes with a LCG.

Christian