Marc-Andre Lemburg added the comment: On 09.06.2016 10:07, Larry Hastings wrote: > > I +1 on new functions that are designated the best-practice places to get > your pseudo-random numbers. > > (IDK if the best place for both is in random; maybe the crypto one should be > in secrets?)
All up for discussion. As long as we get the separation clear, I'm fine with any location in the stdlib. > To be precise: on most OSes what you're calling "crypto random data" is > actually "crypto-quality pseudo-random data". Very few platforms provide > genuine random data--rather, they seed a CPRNG and give you data from that. > (And then the cryptographers have endless arguments about whether the CPRNG > is really crypto-safe.) Yes, I know, this should be documented in the docs for random.cryptorandom(). We might even make the available entropy available as additional API, on platforms where this is possible, or even add APIs to access the entropy daemon where available: http://egd.sourceforge.net/ (the necessary API is available via OpenSSL: http://linux.die.net/man/3/rand_egd) Some crypto applications do need to know a bit more about where the random data is coming from, e.g. for generation of root certificates and secure one time pads. > I'm -1 on actually deprecating os.urandom(). It should be left alone, as a > thin wrapper around /dev/urandom. I imagine your cryptorandom() and > pseudorandom() functions would usually be written in Python and just import > and use the appropriate function on a platform-by-platform basis. Fair enough. I don't feel strong about this part. The main idea here was to move people away from thinking that we can fix a broken system, which is not under our control (because it's a shim on an OS device). How we implement the functions is up to debate as well. I could imaging that we expose the getrandom() function as e.g. random._getrandom() and then use this from Python where available, with fallbacks to other solutions where necessary. This would also make it possible to have similar functionality on non-CPython platforms and opens up the door for future changes without breaking applications again. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27279> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com