[issue27279] Add random.cryptorandom() and random.pseudorandom, deprecate os.urandom()

[Marc-Andre Lemburg]

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 <report at bugs.python.org>
<http://bugs.python.org/issue27279>
_______________________________________