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 gurnec
Recipients christian.heimes, gurnec, mark.dickinson, rhettinger, serhiy.storchaka, skip.montanaro
Date 2015-04-23.16:14:47
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1429805687.51.0.292860810145.issue23974@psf.upfronthosting.co.za>
In-reply-to
Content
> If you have to care about security, you shouldn't use the random module
> at all. random.SystemRandom() merely uses a CPRNG as entropy source. But
> It also manipulates numbers in ways that may or may not be safe.

I must respectfully disagree with this. The current docs say:

> Use os.urandom() or SystemRandom if you require a cryptographically
> secure pseudo-random number generator.

That's a pretty strong statement, and IMO it would lead most to believe that SystemRandom along with *all* of its member functions is safe to use for cryptographic purposes[1] (assuming of course that os.urandom() is also a safe CSPRNG).

As a compromise, perhaps SystemRandom could provide its own randrange() with the #9025 fix, while keeping random.randrange() unmodified to preserve the implied same-sequence rule.


[1] I don't mean to imply that this bias bug necessarily is a cryptographic safety issue--it seems unlikely to me that it is one, however not being a cryptographer myself, I'd rather not draw any conclusions either way, and instead I'd prefer to err on the side of safety.
History
Date User Action Args
2015-04-23 16:14:47gurnecsetrecipients: + gurnec, skip.montanaro, rhettinger, mark.dickinson, christian.heimes, serhiy.storchaka
2015-04-23 16:14:47gurnecsetmessageid: <1429805687.51.0.292860810145.issue23974@psf.upfronthosting.co.za>
2015-04-23 16:14:47gurneclinkissue23974 messages
2015-04-23 16:14:47gurneccreate