Author vstinner
Recipients Arfrever, christian.heimes, loewis, rhettinger, vstinner
Date 2012-06-27.23:25:36
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1340839538.95.0.477475728545.issue15206@psf.upfronthosting.co.za>
In-reply-to
Content
> However a MT isn't suitable for cryptographic purposes.
> The module should first try to use os.urandom() and
> then perhaps use its own instance of random.Random,
> similar to uuid_generate_* [1]

os.urandom() is not suitable for cryptographic purposes :-) Python 3.3 has also ssl.RAND_bytes() which is better than os.urandom(), but it's not possible (easy?) to build a custom random.Random class with an arbitrary RNG (like os.urandom or ssl.RAND_bytes).

It would be nice to provide an API to choose the best RNG depending on a set of requirements. I wrote the Hasard library which implements such idea: the library provides "profiles" and chooses the best RNG for a profile. Profiles:
- fast
- secure nonblocking
- secure blocking
- hardware

See the doc directory the Hasard project for details:
https://bitbucket.org/haypo/hasard/
https://bitbucket.org/haypo/hasard/src/82d13450c552/doc/profile_list.rst

See also the issue #12858 for another user of a better RNG.

I'm quite sure that all these RNG issues are a good candidate for a PEP because RNG is complex problem, there are different use cases, various implements, and a lot of common issue (in RNG implementations). Handling fork or not is an important question, which impact performances, for example.

See also the issue #12754: "Add alternative random number generators".
History
Date User Action Args
2012-06-27 23:25:39vstinnersetrecipients: + vstinner, loewis, rhettinger, christian.heimes, Arfrever
2012-06-27 23:25:38vstinnersetmessageid: <1340839538.95.0.477475728545.issue15206@psf.upfronthosting.co.za>
2012-06-27 23:25:38vstinnerlinkissue15206 messages
2012-06-27 23:25:37vstinnercreate