report at bugs
Jun 27, 2012, 4:25 PM
Post #8 of 16
STINNER Victor <victor.stinner [at] gmail> added the comment:
[issue15206] uuid module falls back to unsuitable RNG
[In reply to]
> 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_* 
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:
- secure nonblocking
- secure blocking
See the doc directory the Hasard project for details:
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".
Python tracker <report [at] bugs>
Python-bugs-list mailing list