[Python-ideas] Globally configurable random number generation

[Stefan Krah]

Sturla Molden <sturla.molden at ...> writes:
> On 14/09/15 15:43, Stefan Krah wrote:
> 
> > These are sane, unambiguously named APIs. I wish Python had more
> > of those.  If people must have their CSPRNG, please let's leave
> > the random module alone and introduce a crypto module like Go.
 
> A crypto module would perhaps be great, but it does not solve anything. 
> Someone who uses random.random instead of os.urandom is likely to use 
> random.random instead of a PRNG in a crypto module as well. Mostly this 
> is about propagating knowledge of random number generators to new 
> developers and science students.

The sentiments in the original thread (which has now been renamed two
times), seem to have been lost:

Theo:
=====

"chacha arc4random is really fast.

if you were to create such an API in python, maybe this is how it will
go:

say it becomes arc4random in the back end.  i am unsure what advice to
give you regarding a python API name.  in swift, they chose to use the
same prefix "arc4random" (id = arc4random(), id = arc4random_uniform(1..n)";
it is a little bit different than the C API.  google has tended to choose
other prefixes.   we admit the name is a bit strange, but we can't touch
the previous attempts like drand48....

I do suggest you have the _uniform and _buf versions.  Maybe apple
chose to stick to arc4random as a name simply because search engines
tend to give above average advice for this search string?"


Theo:
=====

"that opens /dev/urandom or uses the getrandom system call depending on
system.  it also has support for the windows entropy API.  it pulls
data into a large buffer, a cache.  then each subsequent call, it
consumes some, until it rus out, and has to do a fresh read.  it
appears to not clean the buffer behind itself, probably for
performance reasons, so the memory is left active.  (forward secrecy
violated)

i don't think they are doing the best they can...  i think they should
get forward secrecy and higher performance by having an in-process
chacha.  but you can sense the trend."


So the original thread is about:
================================

  - Inplementing a possibly faster (and allegedly more secure)
    chacha20-random.

  - Possibly using the naming scheme of Swift.

  - Being careful with os.urandom(), as there are some pitfalls that
    the OpenBSD libcrypto (allegedly) solves.


I see nothing about magically repurposing random.random() functions.



Stefan Krah