---------- Forwarded message ----------
From: Theo de Raadt
Date: Wed, Sep 9, 2015 at 9:59 AM
Subject: Re: getentropy, getrandom, arc4random()
To: guido@python.org


> Thanks. And one last thing: unless Go and Swift, Python has no significant
> corporate resources behind it -- it's mostly volunteers begging their
> employers to let them work on Python for a few hours per week.

i understand because I find myself in the same situation.

however i think you overstate the difficulty involved.

high-availibility random is kind of a new issue.

so final advice from me; feel free to forward as you like.

i think arc4random would be a better API to call on the back side than
getentropy/getrandom.

arc4random can seed initialize with a single getentropy/getrandom call
at startup.  that is done automatically.  you can then use
arc4random's results to initialize the MT.  in a system call trace,
this will show up as one getentropy/getrandom at process startup,
which gets both subsystems going.  really cheap.

in the case of longer run times, the userland arc4random PRNG folding
reduces the system calls required.  this helps older kernels with
slower entropy creation, taking pressure off their subsystem.  driving
everyone towards this one API which is so high performance is the
right goal.

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?

so arc4random is natively available in freebsd, macos, solaris, and
other systems like andriod libc (bionic).  some systems lack it:
win32, glibc, hpux, aix, so we wrote replacements for libressl:

https://github.com/libressl-portable/openbsd/tree/master/src/lib/libcrypto/crypto
https://github.com/libressl-portable/portable/tree/master/crypto/compat

the first is the base openbsd tree where we maintain/develop this code
for other systems, the 2nd part is scaffold in libressl that makes this
available to others.

it contains arc4random for those systems, and supplies getentropy()
stubs for challenged systems.

we'll admit we haven't got solutions for every system known to man.
we are trying to handle fork issues, and systems with very bad
entropy feeding.

that's free code.  the heavy lifting is done, and we'll keep maintaining
that until the end of days.  i hope it helps.