[Python-ideas] Globally configurable random number generation
skrah at bytereef.org
Mon Sep 14 16:50:13 CEST 2015
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:
"chacha arc4random is really fast.
if you were to create such an API in python, maybe this is how it will
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?"
"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
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)
- 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.
More information about the Python-ideas