Message232471
RAND_bytes() has an annoying bug: it can produces the same byte sequence in two different processes if they get the same identifier (yes, it occurs sometimes). See the issue #18747 and warnings about fork in the ssl module. I don't know if it is now fixed in OpenSSL or maybe in LibreSSL. I was surprised that such bug exist in a serious library designed for cryptography. The usual reply to bug report is that users have to inject entropy manually at fork. It may be possible in an application, the issue #18747 explains why it is not a good idea to that in Python. /dev/urandom doesn't have such issue...
I made the change to expose RAND_bytes(). I made it for my Hasard program (expermental tool to learn PRNG), to easily test the OpenSSL library in Python. That's how I "discovered" the fork issue (it was already known in fact..). I never used ssl.RAND_bytes() in a (real) Python application.
http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ gives good reasons to not use ssl.RAND_bytes. So rand.diff looks good to me. |
|
Date |
User |
Action |
Args |
2014-12-11 11:45:40 | vstinner | set | recipients:
+ vstinner, alex, docs@python, dstufft |
2014-12-11 11:45:40 | vstinner | set | messageid: <1418298340.35.0.866199120398.issue23025@psf.upfronthosting.co.za> |
2014-12-11 11:45:40 | vstinner | link | issue23025 messages |
2014-12-11 11:45:39 | vstinner | create | |
|