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

[Christian Heimes]

Christian Heimes added the comment:

On 2016-06-09 10:30, Marc-Andre Lemburg wrote:
> 
> 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:

EDG has died about 15 years ago. Please don't reanimate it.

> 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.

No, that is not how applications deal with certificates or OTPs. When an
application is really, REALLY concerned with RNG source on that level,
it will never ever use Python or even a Kernel CSPRNG to generate
private keys. Instead it will use a certified, industrial grade HSM
(hardware security model) to offload all cryptographic operations on a
secure device.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27279>
_______________________________________