STINNER Victor <victor.stin...@gmail.com> added the comment: > 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". ---------- nosy: +haypo _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue15206> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
