[issue15206] uuid module falls back to unsuitable RNG

STINNER Victor added the comment: I close the issue. Python 3.7 and newer are fixed. Python 2.7 is still affected, but I consider that it's ok to leave the bug unfixed in this version. -- > The random number generator now reseeds after a fork. I confirm that it's done since Python 3.7, and

[issue15206] uuid module falls back to unsuitable RNG

Raymond Hettinger added the comment: The random number generator now reseeds after a fork. Can this now be closed as "out-of-date" or is there still something that needs to be done? -- status: pending -> open ___ Python tracker

[issue15206] uuid module falls back to unsuitable RNG

Christian Heimes added the comment: Past me was a bit too eager... Only UUID4 are suppose to be random and unpredictable. uuid.UUID4 uses os.urandom() to as RNG. UUID1, UUID3 and UUID5 are more concerned with reducing collisions. -- status: open -> pending type: security -> behavior

[issue15206] uuid module falls back to unsuitable RNG

STINNER Victor added the comment: > Given the introduction of the secrets module in 3.6, perhaps uuid could be > updated to fall back to that rather than to the random module and leave older > versions unmodified? issue15206.patch catchs exceptions on random.SystemRandom error, but the secret

[issue15206] uuid module falls back to unsuitable RNG

Nick Coghlan added the comment: Given the introduction of the secrets module in 3.6, perhaps uuid could be updated to fall back to that rather than to the random module and leave older versions unmodified? -- nosy: +ncoghlan versions: +Python 3.6 -Python 3.2, Python 3.3 __

[issue15206] uuid module falls back to unsuitable RNG

Antoine Pitrou added the comment: > The rest of the module uses bar excepts. It was probably written in prehistoric times :) The other excepts can be converted later, if the module gets other changes. I don't think it is a deliberate style choice (it would be particularly distasteful :-)). -

[issue15206] uuid module falls back to unsuitable RNG

Christian Heimes added the comment: The rest of the module uses bar excepts. I could change the signature if you insist. -- ___ Python tracker ___ _

[issue15206] uuid module falls back to unsuitable RNG

Antoine Pitrou added the comment: +except Exception: I don't think that's a good idea. You should list the specific exceptions here (NotImplementedError, OSError perhaps?). -- ___ Python tracker

[issue15206] uuid module falls back to unsuitable RNG

Christian Heimes added the comment: Am 28.06.2012 07:54, schrieb Martin v. Löwis: > > Martin v. Löwis added the comment: > >> a) my patch handles the fork() issue correctly > > If the system has urandom, yes. That's the easy and trivial case. It also handles fork() by storing the PID and co

[issue15206] uuid module falls back to unsuitable RNG

Changes by Martin v. Löwis : -- versions: -Python 2.6, Python 3.1 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue15206] uuid module falls back to unsuitable RNG

Martin v. Löwis added the comment: > a) my patch handles the fork() issue correctly If the system has urandom, yes. > b) if it's a good idea to try SystemRandom first Certainly. > c) a backport to 2.6, 2.7, 3.1 and 3.2 is required > and perhaps Cannot backport to 2.6 and 3.1; it's not a sec

[issue15206] uuid module falls back to unsuitable RNG

Christian Heimes added the comment: Antoine beat me to it and he is totally right. Please don't derail this bug report. I agree with your analysis that the RNG core of random.Random subclass can't be replaced easily and that more implementations for different purposes would be great. You shou

[issue15206] uuid module falls back to unsuitable RNG

Antoine Pitrou added the comment: >From the /dev/urandom Linux man page: If you are unsure about whether you should use /dev/random or /dev/urandom, then probably you want to use the latter. As a general rule, /dev/urandom should be used for everything exc

[issue15206] uuid module falls back to unsuitable RNG

STINNER Victor added the comment: > However a MT isn't suitable for cryptographic purposes. > The module should first try to use os.urandom() and > then perhaps use its own instance of random.Random, > similar to uuid_generate_* [1] os.urandom() is not suitable for cryptographic purposes :-) Py

[issue15206] uuid module falls back to unsuitable RNG

Christian Heimes added the comment: Not, not by definition. However an uuid generator shall geenerate uuid in a way that make collisions highly improbable. IMHO this verdict implies that an uuid generator should use the cryptographic RNG if available. The behavior after fork() is clearly a bu

[issue15206] uuid module falls back to unsuitable RNG

Raymond Hettinger added the comment: Are uuid's promised to be cryptographically secure? -- assignee: -> rhettinger nosy: +rhettinger ___ Python tracker ___ ___

[issue15206] uuid module falls back to unsuitable RNG

Christian Heimes added the comment: IMHO it's all about managing expectations. As libuuid is using a crypto RNG before it falls back to a less suitable RNG. We should follow this example. I couldn't find any information about the implementation details of Window's UuidCreate(). I agree that

[issue15206] uuid module falls back to unsuitable RNG

Martin v. Löwis added the comment: Can you elaborate why it is unsuitable? None of the uuid functions claim any cryptographic properties, so even if MT was unsuitable for cryptographic purposes, this wouldn't rule it out for generating uuids. -- nosy: +loewis

[issue15206] uuid module falls back to unsuitable RNG

Christian Heimes added the comment: Further analysis: * uuid1() uses random.randrange() if the system doesn't provide uuid_generate_time * uuid1() also falls back to random.randrange() in getnode()'s _random_getnode() if no hardware address can be acquired. * uuid4() is fine as it only fall

[issue15206] uuid module falls back to unsuitable RNG

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue15206] uuid module falls back to unsuitable RNG

New submission from Christian Heimes : The uuid module uses Mersenne Twister from the random module as last fallback. However a MT isn't suitable for cryptographic purposes. The module should first try to use os.urandom() and then perhaps use its own instance of random.Random, similar to uuid_