This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author dstufft
Recipients Colm Buckley, Lukasa, alex, christian.heimes, doko, dstufft, larry, lemburg, martin.panter, matejcik, ned.deily, python-dev, rhettinger, skrah, thomas-petazzoni, vstinner, ztane
Date 2016-06-07.17:36:53
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> 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

I think either the first or second here are good solutions, the third is kind of crummy on it's own because it's not always possible to pass in an environment variable. Pairing the third with a CLI flag option might work out nice though, perhaps a -XPYTHONHASHSEED=(random/int()) or something. Then folks who are in early boot can easily just hardcode a hash seed, removing the need to hit the entropy pools while still maintaining strong random for everyone else.

So I guess I would lean towards adding a CLI flag, but just allowing SipHash to fall back to possibly bad randomness for it's initialization is OK.

>  * accept Victor's existing changeset without my nonblocking_urandom_noraise patch, which makes _PyOS_URandom nonblocking in all Linux cases.
>  * resolve as above (both Victor's and my patches), and require that applications be modified to work correctly
>  * require modifications to and to use nonblocking sources and/or raise exceptions accordingly.

Of these, I think should just not use a CSPRNG, it's not required for it so there's no reason to do it. I don't think there's actually any problem with hashlib, I don't see any use of random in it.

> I would be interested in PSRT's assessment of an actual attack on a predictable hash secret 

For something like systemd-crontab-generator, basically nothing-- for anything short lived or which does not provide a means for arbitrary users to put data into a dictionary. IOW, it's largely persistent network services.
Date User Action Args
2016-06-07 17:36:53dstufftsetrecipients: + dstufft, lemburg, rhettinger, doko, vstinner, larry, christian.heimes, matejcik, ned.deily, alex, skrah, python-dev, martin.panter, ztane, Lukasa, thomas-petazzoni, Colm Buckley
2016-06-07 17:36:53dstufftsetmessageid: <>
2016-06-07 17:36:53dstufftlinkissue26839 messages
2016-06-07 17:36:53dstufftcreate