Re: [Python-Dev] PEP 506 secrets module

On Fri, Oct 16, 2015 at 08:57:24AM +0200, Victor Stinner wrote:
> 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.

Youtube URLs have what looks like about 8 or 9 bytes of randomness:

https://www.youtube.com/watch?v=B3KBuQHHKx0

(assuming it is base64 encoded, 11 chars is about 8 or 9 bytes). I don't 
think that we should force people to use any specific length, it would 
be pointless since they can always just slice it:

py> secrets.token_bytes(16)[:2]
b'\xd1s'

Unless anyone has a good argument for why we should do this, I would be 
inclined to allow any value for nbytes. At most, I would be prepared to 
raise a warning if the nbytes was less than 16, but I don't think an 
error is appropriate.

Thoughts?


> 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)

Wouldn't help(randrange) be easier? :-)

    Choose a random item from range(start, stop[, step]).

    This fixes the problem with randint() which includes the
    endpoint; in Python this is usually not what you want.


I always find that comment amusing. While it is true that in slicing, 
half-open ranges are more useful than closed ranges, but when it comes 
to generating random numbers (say, simulating dice) I find randint much 
more useful and intuitive.

But I appreciate that some people think differently.


> Hum, ok, it's not a good dice :-) I probably wanted to use randint().> So I suggest to only add randint() to secrets.

On the Python-Ideas list the argument was about equally split between 
those who wanted only randrange and those who wanted only randint. I 
think if we don't supply both, we'll be forever fielding feature 
requests to add in the missing one.


> 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> ;-))

secrets uses os.urandom and random.SystemRandom, which also uses 
os.urandom (or equivalent under Windows). The implementation section of 
the PEP shows that.

As for the reason why urandom rather than /dev/random:

http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/

http://www.2uo.de/myths-about-urandom/


I'm not sure if this was explicitly discussed in Python-Ideas, if it was 
I have forgotten it. I seem to recall that everyone who seemed to know 
what they were talking about just assumed we'd be using os.urandom and 
nobody questioned it or argued.


> 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

Does anyone else think that the secrets module should promise specific 
implementations?



-- 
Steve
_______________________________________________
Python-Dev mailing list
Pyth...@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/python-dev-ml%40activestate.com