Hi, I like the PEP. IMHO it's a better solution than using a CPRNG for random by default.
I suggest to raise an error if token_bytes(n) if calls with n < 16 bytes (128 bits). Well, I'm not sure that 16 is the good compromise between performance and security, but we must enforce users to use a minimum number of bits of entropy. token_bytes(1) looks valid, even token_bytes(0), according to the Python code in the PEP. I don't like the idea how having two functions doing *almost* the same thing: randint() and randrange(). There is a risk that these functions will be misused. I consider that I know some stuff on PRNG but I'm still confused by randint() and randrange(). Usually, I open python and type: >>> x=[s.randrange(1,6) for n in range(100)] >>> min(x), max(x) (1, 5) Hum, ok, it's not a good dice :-) I probably wanted to use randint(). So I suggest to only add randint() to secrets. The PEP doesn't explain if secrets uses a "blocking" CPRNG (like /dev/random or getentropy() on Solaris) or a "non-blocking" CRPNG (like /dev/urandom). And it doesn't explain the rationale. Please explain, or I'm sure that the question will arise (ex: I just asked it ;-)) You may also be a little bit more explicit on the CPRNG: it *looks* like secrets will always use a CRPNG implemented in the kernel. Is it a property of the secrets module, or can it be ssl.RAND_bytes() for example? IMHO we must always use a CRPNG implemented in the kernel, there is still an issue with ssl.RAND_bytes() and fork() (two child process can produce exactly the same random numbers after a lot of fork()...). I understood that OpenSSL developers doesn't want to fix it. You may even be very explicit, list CPRNG that will be used on Python 3.6: * Linux: getrandom() syscall if available (Linux 3.17 or newer), or /dev/urandom * Solaris: getrandom() function if available (Solaris 11.3 or newer), or /dev/urandom * OpenBSD: getentropy() function (OpenBSD 5.6 or newer), or /dev/urandom * Windows: CryptAcquireContext(PROV_RSA_FULL, CRYPT_VERIFYCONTEXT) and CryptGenRandom() * Other UNIXes: /dev/urandom It's still unclear to me if getentropy() on OpenBSD can block or not if the entropy is too low :-/ Victor 2015-10-16 2:57 GMT+02:00 Steven D'Aprano <st...@pearwood.info>: > Hi, > > As extensively discussed on Python-Ideas, the secrets module and PEP 506 > is (I hope) ready for pronouncement. > > https://www.python.org/dev/peps/pep-0506/ > > There is code and tests here: > > https://bitbucket.org/sdaprano/secrets > > > or you can run > > hg clone https://sdapr...@bitbucket.org/sdaprano/secrets > > > The code is written for and tested on Python 2.6, 2.7, 3.1 - 3.4. > > > > -- > Steve > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
