Created on 2012-06-27 14:01 by christian.heimes, last changed 2012-07-01 18:40 by pitrou.
|issue15206.patch||christian.heimes, 2012-06-27 21:11||review|
|msg164157 - (view)||Author: Christian Heimes (christian.heimes) *||Date: 2012-06-27 14:01|
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_*  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.  http://linux.die.net/man/3/uuid_generate
|msg164181 - (view)||Author: Christian Heimes (christian.heimes) *||Date: 2012-06-27 18:10|
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.
|msg164185 - (view)||Author: Martin v. Löwis (loewis) *||Date: 2012-06-27 18:29|
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.
|msg164203 - (view)||Author: Christian Heimes (christian.heimes) *||Date: 2012-06-27 21:11|
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.
|msg164207 - (view)||Author: Raymond Hettinger (rhettinger) *||Date: 2012-06-27 22:22|
Are uuid's promised to be cryptographically secure?
|msg164210 - (view)||Author: Christian Heimes (christian.heimes) *||Date: 2012-06-27 22:44|
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.
|msg164211 - (view)||Author: STINNER Victor (haypo) *||Date: 2012-06-27 23:25|
> 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_*  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".
|msg164212 - (view)||Author: Antoine Pitrou (pitrou) *||Date: 2012-06-27 23:29|
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).
|msg164213 - (view)||Author: Christian Heimes (christian.heimes) *||Date: 2012-06-27 23:38|
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.
|msg164221 - (view)||Author: Martin v. Löwis (loewis) *||Date: 2012-06-28 05:54|
> 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.
|msg164230 - (view)||Author: Christian Heimes (christian.heimes) *||Date: 2012-06-28 09:05|
Am 28.06.2012 07:54, schrieb Martin v. Löwis: > > Martin v. Löwis <firstname.lastname@example.org> 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.
|msg164231 - (view)||Author: Antoine Pitrou (pitrou) *||Date: 2012-06-28 09:27|
+ except Exception: I don't think that's a good idea. You should list the specific exceptions here (NotImplementedError, OSError perhaps?).
|msg164484 - (view)||Author: Christian Heimes (christian.heimes) *||Date: 2012-07-01 15:42|
The rest of the module uses bar excepts. I could change the signature if you insist.
|msg164492 - (view)||Author: Antoine Pitrou (pitrou) *||Date: 2012-07-01 18:40|
> 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 :-)).
|2012-07-01 18:40:55||pitrou||set||messages: + msg164492|
|2012-07-01 15:42:35||christian.heimes||set||messages: + msg164484|
|2012-06-28 09:27:29||pitrou||set||messages: + msg164231|
|2012-06-28 09:05:06||christian.heimes||set||messages: + msg164230|
|2012-06-28 05:55:35||loewis||set||versions: - Python 2.6, Python 3.1|
|2012-06-28 05:54:51||loewis||set||messages: + msg164221|
|2012-06-27 23:38:28||christian.heimes||set||messages: + msg164213|
messages: + msg164212
messages: + msg164211
|2012-06-27 22:44:18||christian.heimes||set||messages: + msg164210|
|2012-06-27 22:22:11||rhettinger||set||assignee: rhettinger|
messages: + msg164207
nosy: + rhettinger
keywords: + patch
messages: + msg164203
messages: + msg164185
|2012-06-27 18:10:54||christian.heimes||set||messages: + msg164181|