| msg93678 - (view) |
Author: Shawn Ligocki (sligocki) |
Date: 2009-10-07 05:48 |
| I did not notice the existence of random.SystemRandom until after I had implemented my own version. I thought it would be nice to mention it in the opening section. I've added a tiny note about random.SystemRandom. What do you guys think, feel free to reword it, I just think that it should be mentioned. http://docs.python.org/library/random.html |
|
|
| msg93679 - (view) |
Author: Jan (chuck) * |
Date: 2009-10-07 06:13 |
| I think non-determinism is more then os.urandom can deliver. As far as I know the OS still does deterministic calculations, though they are maybe less obvious. Maybe call it "safer, OS dependent"? |
|
|
| msg93680 - (view) |
Author: Raymond Hettinger (rhettinger) *  |
Date: 2009-10-07 06:55 |
| FWIW, the docs for os.urandom() state: """Return a string of n random bytes suitable for cryptographic use. This function returns random bytes from an OS-specific randomness source. The returned data should be unpredictable enough for cryptographic applications, though its exact quality depends on the OS implementation. On a UNIX-like system this will query /dev/urandom, and on Windows it will use CryptGenRandom. """ |
|
|
| msg93682 - (view) |
Author: Shawn Ligocki (sligocki) |
Date: 2009-10-07 08:27 |
| Oh, urandom is almost always non-deterministic. It mixes completely random bits from hardware sources with its pseudo-random number state. The more random bits it gets from hardware, the less predictable its output is. However, as long as it's getting any random bits, it's output is not deterministic (because it's based on some random information). But perhaps there is better wording that conveys the power of the urandom source? |
|
|
| msg93683 - (view) |
Author: Jan (chuck) * |
Date: 2009-10-07 08:45 |
| Maybe os.urandom is "more random" than the module random in the sense that it is harder to figure out what comes next, but still deterministic. The readings from the hardware are random and you usually don't know them, yet what comes out of urandom is determined by what urandom reads from the hardware and its state. I just want to warn not to drop wrong terms. |
|
|
| msg93684 - (view) |
Author: Shawn Ligocki (sligocki) |
Date: 2009-10-07 09:08 |
| Ah, sorry for the misunderstanding. I agree, better not to mislead. Perhaps we should side with the urandom documentation and say that it is a cryptographically secure random number generator with no accessible state? |
|
|
| msg93688 - (view) |
Author: Jan (chuck) * |
Date: 2009-10-07 09:35 |
| Depends on how verbose we want to be. It should say why one might want to use urandom() instead of random (if you decide you are interested you can still look up the documentation). I think it would be nice to say why random does not use urandom if urandom is better, so you end up with a very short pro/con of urandom, which should be appropriate for users who are seeking information on getting random numbers. Unfortunately I don't know enough about random. I guess it's a speed/security tradeoff? |
|
|
| msg93726 - (view) |
Author: Shawn Ligocki (sligocki) |
Date: 2009-10-07 21:46 |
| A major pro for pseudo-random number generators is that they are deterministic, that is, you can save a load the state, start from the same seed and reproduce results, etc. At least in science (and probably other areas) this reproducibility can be vital in a random class. It really depends on your application though. In my use, I was originally using normal random to produce seeds for another programs random number generator. This ended up producing many identical results and thus not producing an appropriate random sampling. Rather than trying to figure out a proper way to do this with a PRNG I decided to just use a completely random source, urandom was close enough for my needs. I believe that is its strongest value, not having the strange artifacts that PRNGs have. But I'm not completely sure how true that claim is :) |
|
|
| msg94839 - (view) |
Author: Shawn Ligocki (sligocki) |
Date: 2009-11-02 20:29 |
| I rewrote the description, mostly using the claims form urandom, so that we don't claim something new. What do you guys think? |
|
|
| msg94840 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2009-11-02 20:40 |
| The wording looks reasonable but it doesn't seem to add much that is not already said: ''' class SystemRandom( [seed]) Class that uses the os.urandom() function for generating random numbers from sources provided by the operating system. Not available on all systems. Does not rely on software state and sequences are not reproducible. Accordingly, the seed() and jumpahead() methods have no effect and are ignored. The getstate() and setstate() methods raise NotImplementedError if called. ''' I hesitate to include anything about cryptographic strength because that isn't really guaranteed on any system. At best, there are a fixed number of bytes of machine generated entropy. At worst, it is deterministic (computed from time, etc) or it is not available at all. |
|
|
| msg94841 - (view) |
Author: Shawn Ligocki (sligocki) |
Date: 2009-11-02 20:44 |
| So, all I really want to do is call attention to SystemRandom from the top of the page, because it is easily not noticed at the bottom. Do you guys have any suggestions for how to do that that doesn't repeat too much and doesn't claim things that you aren't comfortable with claiming? |
|
|
| msg94842 - (view) |
Author: Shawn Ligocki (sligocki) |
Date: 2009-11-02 20:46 |
| How about this, sweet and simple. |
|
|
| msg94846 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2009-11-02 21:12 |
| I'm disinclined to move this to the top of the page but will keep this open and consider further at a later date. The SystemRandom class is an alternative generator like WichmanHill which is typically not the right choice for many applications. |
|
|
| msg94847 - (view) |
Author: Shawn Ligocki (sligocki) |
Date: 2009-11-02 21:21 |
| There is a whole paragraph about WichmanHill at the top of this page already and (if anything) I think that WichmanHill is less notable (basically only used in legacy applications). However SystemRandom is very useful. I don't want to make claims about urandom that I can't back up, but urandom is very useful and I think that there ought to be some note of it in the opening for people who want a stronger random instance. All I'm suggesting is a sentence to point it out. That would have been enough for me not to have reinvented the wheel. |
|
|
| msg94859 - (view) |
Author: Jan (chuck) * |
Date: 2009-11-03 08:25 |
| I think many people who are looking for a random number generator end up on this page and need to be informed if there are alternatives so they can make up their own mind. If you want to discourage people to use it, that's fine and we can do so, but I think it's wrong to hide it from people who don't suspect random functions which are os dependent to be in the os package instead of the random package or don't even know about the os random facility. |
|
|
| msg98136 - (view) |
Author: Shawn Ligocki (sligocki) |
Date: 2010-01-22 05:38 |
| ping Please look at the last patch. It's very simple and would be helpful. This is not very complicated and shouldn't take months to consider. |
|
|
| msg98151 - (view) |
Author: David W. Lambert (LambertDW) |
Date: 2010-01-22 16:09 |
| I recall an experience with a random file in /dev that was considerably slow after consuming its cache. I used it as a seeder. I've now got an ubuntu system for which /dev/urandom gives me a hundred million bytes quickly. Perhaps a nosy one has more information? |
|
|
| msg98500 - (view) |
Author: Shawn Ligocki (sligocki) |
Date: 2010-01-29 06:28 |
| ping |
|
|
| msg99704 - (view) |
Author: A.M. Kuchling (akuchling) * |
Date: 2010-02-22 02:32 |
| Committed to 2.7 as r78297. I modified the patch yet further, just describing the SystemRandom class and leaving the versionchanged text about MersenneTwister/Wichman-Hill where it was, though I edited it to be clearer. |
|
|