I'm just going to forward further missives by Theo. ---------- 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/c... 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. -- --Guido van Rossum (python.org/~guido)