homepage

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_generate_* [1]
The problem doesn't apply to most modern platforms as the uuid module uses either libuuid or the Windows API with ctypes. Therefore I consider the real world severity as low. It may not require a backport to Python 2.x.
[1] http://linux.die.net/man/3/uuid_generate 

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 falls back to random.randrange() when os.urandom() fails.

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.

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 we can disagree on my reasoning. However the usage of random.random() and random.randint() in uuid is flawed for a second reason. The default instance random._inst doesn't compensate for fork(). After fork() the two processes share the same random state and thus will create the same uuids. For example tempfile._RandomNameSequence re-creates the RNG when it notices a different PID.

Are uuid's promised to be cryptographically secure?

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 bug as it will generate lots of collisions on systems that fall back to random.

> 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 :-) Python 3.3 has also ssl.RAND_bytes() which is better than os.urandom(), but it's not possible (easy?) to build a custom random.Random class with an arbitrary RNG (like os.urandom or ssl.RAND_bytes).
It would be nice to provide an API to choose the best RNG depending on a set of requirements. I wrote the Hasard library which implements such idea: the library provides "profiles" and chooses the best RNG for a profile. Profiles:
- fast
- secure nonblocking
- secure blocking
- hardware
See the doc directory the Hasard project for details:
https://bitbucket.org/haypo/hasard/
https://bitbucket.org/haypo/hasard/src/82d13450c552/doc/profile_list.rst
See also the issue #12858 for another user of a better RNG.
I'm quite sure that all these RNG issues are a good candidate for a PEP because RNG is complex problem, there are different use cases, various implements, and a lot of common issue (in RNG implementations). Handling fork or not is an important question, which impact performances, for example.
See also the issue #12754: "Add alternative random number generators".

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 except long-lived
 GPG/SSL/SSH keys.
 If a seed file is saved across reboots as recommended below (all major
 Linux distributions have done this since 2000 at least), the output is
 cryptographically secure against attackers without local root access as
 soon as it is reloaded in the boot sequence, and perfectly adequate for
 network encryption session keys. 
So, yes, /dev/urandom is suitable for most cryptographic purposes (except long-lived private keys).

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 should stick the analysis into a different ticket or write a PEP. This ticket is the wrong place. I'll support you if you keep the ticket on course. ;)
Let's concentrate on the topic at hand and discuss if 
a) my patch handles the fork() issue correctly
b) if it's a good idea to try SystemRandom first
c) a backport to 2.6, 2.7, 3.1 and 3.2 is required
and perhaps
d) if I should open another ticket to work on a general solution for the RNG + fork() issue.

> 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 security issue.
> d) if I should open another ticket to work on a general solution for 
> the RNG + fork() issue.
I'm not quite sure what a solution could be, or wether there is
an issue in the first place, so -0.

Am 28.06.2012 07:54, schrieb Martin v. Löwis:
> 
> Martin v. Löwis <martin@v.loewis.de> 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 comparing it to os.getpid() whenever the RNG is acquired.

+ except Exception:
I don't think that's a good idea. You should list the specific exceptions here (NotImplementedError, OSError perhaps?).

The rest of the module uses bar excepts. I could change the signature if you insist.

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

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?

> 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 secrets module also uses random.SystemRandom. I don't think that "fallback on secrets" makes sense here, or do I miss something?

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.

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?

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 Python 3.6 doesn't accept bugfixes anymore (only security fixes). So the issue is fixed in Python 3.7, 3.8 and master. For the record, the fix was this change:
commit 346cbd351ee0dd3ab9cb9f0e4cb625556707877e
Author: Antoine Pitrou <pitrou@free.fr>
Date: Sat May 27 17:50:54 2017 +0200
 bpo-16500: Allow registering at-fork handlers (#1715)
Backporting this change to Python 3.6 and 3.5 would be too intrusive and risky. I don't think that this bug is important enough to be qualified as security vulnerability (the issue type is not "Security").
For Python 2.7, honestly, I don't think that the issue matters enough to justify to fix it today, knowning that Python 2.7 will reach its end of life at the end of the year. Moreover, apart Christian Heimes, no user ever complained about this issue.
Note: uuid.uuid4() always used os.urandom(16) which is not affected by this issue on fork. Only uuid.uuid1() and uuid.getnode() has the bug in Python 2.7.