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 ncoghlan
Recipients Lukasa, docs@python, georg.brandl, larry, martin.panter, ncoghlan, ned.deily, steven.daprano, vstinner
Date 2016-09-10.08:27:49
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1473496069.86.0.434402789307.issue27292@psf.upfronthosting.co.za>
In-reply-to
Content
On modern Intel chips, one of the entropy sources is the CPU itself, and so this problem is mostly theoretical on such systems unless you're worried about the quality of Intel's entropy generation (in which case you're well and truly into sovereign espionage and advanced persistent threat territory, and really shouldn't be blindly trusting operating systems and programming language runtimes to already be doing the right thing).

So the main ways to get bad entropy from /dev/urandom on Linux are:

- a misconfigured VM that has been cut off from all decent entropy sources, and doesn't have any persistent storage attached
- an embedded non-Intel chip that doesn't have any decent entropy sources or persistent storage attached

If you're not doing either of those things, you're probably fine. If you're worried that you might be, try running Python 3.6 and calling os.getrandom() explicitly to see what happens.
History
Date User Action Args
2016-09-10 08:27:49ncoghlansetrecipients: + ncoghlan, georg.brandl, vstinner, larry, ned.deily, steven.daprano, docs@python, martin.panter, Lukasa
2016-09-10 08:27:49ncoghlansetmessageid: <1473496069.86.0.434402789307.issue27292@psf.upfronthosting.co.za>
2016-09-10 08:27:49ncoghlanlinkissue27292 messages
2016-09-10 08:27:49ncoghlancreate