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:
It's still unclear to me if getentropy() on OpenBSD can block or not if the entropy is too low :-/
2015-10-16 2:57 GMT+02:00 Steven D'Aprano firstname.lastname@example.org:
As extensively discussed on Python-Ideas, the secrets module and PEP 506 is (I hope) ready for pronouncement.
There is code and tests here:
or you can run
The code is written for and tested on Python 2.6, 2.7, 3.1 - 3.4.
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.co...