[issue27272] random.Random should not read 2500 bytes from urandom

Changes by Raymond Hettinger : -- resolution: -> not a bug status: open -> closed ___ Python tracker ___

[issue27272] random.Random should not read 2500 bytes from urandom

Changes by Christian Heimes : -- nosy: -christian.heimes ___ Python tracker ___ ___

[issue27272] random.Random should not read 2500 bytes from urandom

Tim Peters added the comment: Christian, you should really be the first to vote to close this. The title of this bug report is about whether it would be good to reduce the _number_ of bytes Random initialization consumes from os.urandom(), not whether to stop using os.urandom() entirely.

[issue27272] random.Random should not read 2500 bytes from urandom

Christian Heimes added the comment: On 2016-06-11 00:07, Raymond Hettinger wrote: > > Raymond Hettinger added the comment: > >> But I'll be happiest if nothing changes here (given that Guido ruled >> yesterday that Python's current urandom() implementation has to be >> reverted to once again

[issue27272] random.Random should not read 2500 bytes from urandom

Martin Panter added the comment: Victor originally opened this mentioning a 256-byte limit. I guess that comes from Open BSD’s getentropy() function: . Solaris’s getrandom() function

[issue27272] random.Random should not read 2500 bytes from urandom

Raymond Hettinger added the comment: > But I'll be happiest if nothing changes here (given that Guido ruled > yesterday that Python's current urandom() implementation has to be > reverted to once again match Linux's non-blocking urandom() behavior). With urandom() behavior restored, can we

[issue27272] random.Random should not read 2500 bytes from urandom

Tim Peters added the comment: Raymond, while I'm in general agreement with you, note that urandom() doesn't deliver "random" bytes to begin with. A CSPRNG is still a PRNG. For example, if the underlying urandom() generator is ChaCha20, _it_ has "only" 512 bits of state. Seeding the Twister

[issue27272] random.Random should not read 2500 bytes from urandom

Raymond Hettinger added the comment: With anything less than than full seeding of the 19937-bit state space, we lose all the guarantees (proved properties) documented at http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/ARTICLES/mt.pdf . It is very nice to be able to rely on those properties

[issue27272] random.Random should not read 2500 bytes from urandom

Tim Peters added the comment: Ah! Yes, .getrandbits(N) outputs remain vulnerable to equation-solving in Python 3, for any value of N. I haven't seen any code where that matters (may be "a security hole"), but would bet some _could_ be found. There's no claim of absolute security here. To

[issue27272] random.Random should not read 2500 bytes from urandom

Donald Stufft added the comment: > Sorry, I don't know what "it" refers to. Surely not to a program exposing > the output of .getstate()?! random.getrandbits() -- ___ Python tracker

[issue27272] random.Random should not read 2500 bytes from urandom

Tim Peters added the comment: > Searching github pulls up a number of results of people > calling it, but I haven't looked through them to see > how/why they're calling it. Sorry, I don't know what "it" refers to. Surely not to a program exposing the output of .getstate()?! Regardless, there

[issue27272] random.Random should not read 2500 bytes from urandom

Donald Stufft added the comment: > But that's not what real-life programs expose. Are you sure? Searching github pulls up a number of results of people calling it, but I haven't looked through them to see how/why they're calling it. > What do you believe? For example, do you believe it would

[issue27272] random.Random should not read 2500 bytes from urandom

Tim Peters added the comment: Donald, your script appears to recreate the state from some hundreds of consecutive outputs of getrandbits(64). Well, sure - but what of it? That just requires inverting the MT's tempering permutation. You may as well note that the state can be recreated from

[issue27272] random.Random should not read 2500 bytes from urandom

Donald Stufft added the comment: If seeding from urandom was causing no problems, then I would not care if random.Random() wanted to seed from urandom, even though it doesn't need to. However it is causing problems, and thus it shouldn't. Here's another script, this one runs on Python 3.5.1

[issue27272] random.Random should not read 2500 bytes from urandom

STINNER Victor added the comment: > On 'import random' seed random.Random() from _Py_HashSecret.random_seed + > gettimeofday().tv_sec + gettimeofday().tv_usec + id(self). That way > subinterpreters get a different init state. Can we use os.urandom() was random.Random is instanciated manually,

[issue27272] random.Random should not read 2500 bytes from urandom

Christian Heimes added the comment: New plan: * Add a new uint64 _Py_HashSecret.random_seed * On 'import random' seed random.Random() from _Py_HashSecret.random_seed + gettimeofday().tv_sec + gettimeofday().tv_usec + id(self). That way subinterpreters get a different init state. On systems

[issue27272] random.Random should not read 2500 bytes from urandom

Christian Heimes added the comment: Tim, you are saying that some methods (e.g. randint) of the MT don't fail security properties as bad as other. I'm sorry, that argument is not good enough for me. The seed() method of the MT is causing real-world problems, e.g. #25420 where 'import random'

[issue27272] random.Random should not read 2500 bytes from urandom

Tim Peters added the comment: Donald, it does matter. The code you found must be using some older version of Python, because the Python 3 version of randint() uses _randbelow(), which is an accept/reject method that consumes an _unpredictable_ number of 32-bit Twister outputs. That utterly

[issue27272] random.Random should not read 2500 bytes from urandom

Donald Stufft added the comment: Tim, If MT is used in any of the security sensitive contexts that paper mentions, then it doesn't matter if you seed it with a static zero or a billion bytes read from the purest of purestrain randomness, your application is broken. In other words, it doesn't

[issue27272] random.Random should not read 2500 bytes from urandom

Tim Peters added the comment: Didn't anyone here follow the discussion about the `secrets` module? PHP was crucified by security wonks for its horridly naive ways of initializing its PRNGs: https://media.blackhat.com/bh-us-12/Briefings/Argyros/BH_US_12_Argyros_PRNG_WP.pdf Please don't even

[issue27272] random.Random should not read 2500 bytes from urandom

Martin Panter added the comment: If the seed is to be based on time.time(), why not use something based on hash(time.time()) to avoid the 1/256 s resolution? If there is a practical way to get pseudo-random data from the platform, it would be better to use that, rather than cooking up our own

[issue27272] random.Random should not read 2500 bytes from urandom

Donald Stufft added the comment: One of the key take aways though is that MT doesn't really *need* to be initialized with a CSPRNG, all it needs it some moderately random data. So we can eliminate the case all together by just not using it. Though a sticking point is that it's documented to

[issue27272] random.Random should not read 2500 bytes from urandom

Donald Stufft added the comment: To be clear, that was a minimal patch using a method that already existing. It could be made a lot better by mixing in other sources of entropy like PID#, id(self), etc. -- ___ Python tracker

[issue27272] random.Random should not read 2500 bytes from urandom

STINNER Victor added the comment: Donald Stufft proposed the patch no-urandom-by-default.diff in the issue #26839 which replaces os.urandom() with int(time.time()*256) in random.Random constructor. I dislike this change because it becomes more likely that two Python processes produce the

[issue27272] random.Random should not read 2500 bytes from urandom

STINNER Victor added the comment: PHP uses GENERATE_SEED() to initialize mt_rand(): https://github.com/php/php-src/blob/1c295d4a9ac78fcc2f77d6695987598bb7abcb83/ext/standard/php_rand.h#L50 This macro uses: time() (resolution of 1 second), process identifier, php_combined_lcg()

[issue27272] random.Random should not read 2500 bytes from urandom

STINNER Victor added the comment: Related issue #26839. Don't read this very long issue! You can read my summary :-D https://haypo-notes.readthedocs.io/pep_random.html#bug-reports -- ___ Python tracker

[issue27272] random.Random should not read 2500 bytes from urandom

New submission from STINNER Victor: Reading more than 256 bytes from os.urandom() is different than reading 256 bytes or less. For example, see getrandom() and getentropy() manual pages for more details. random.Random doesn't need a very high quality entropy. The glib library only reads 128