On Jun 7, 6:18 am, Robin Becker <ro...@reportlab.com> wrote: > A python web process is producing files that are given randomized names of > the form > > hhhhhh-YYYYMMDDhhmmss-rrrrrrrr.pdf > > where rrr.. is a 128bit random number (encoded as base62). The intent of the > random part is to prevent recipients of one file from being able to guess the > names of others. > > The process was originally a cgi script which meant each random number was > produced thusly > > pid is process id, dur is 4 bytes from /dev/urandom. > > random.seed(long(time.time()*someprimeint)|(pid<<64)|(dur<<32)) > rrr = random.getrandbits(128) > > is this algorithm safe? Is it safe if the process is switched to fastcgi and > the > initialization is only carried out once and then say 50 rrr values are > generated.
How much randomness do you actually have in this scheme? The PID is probably difficult for an attacker to know, but it's allocated roughly monotonically with a known wrap-around value. The time is probably roughly known, so it also contributes less than its full bits to the randomness. Only dur is really unpredictable. So you have something somewhat above 4 bytes of randomness in your seed - perhaps 8 or 10. That's much less than even the fairly small 16 bytes of "randomness" you expose in the filename. The random module is entirely deterministic, so once the seed is known the value you produce is known too. Is 10 bytes enough to thwart your attackers? Hard to say, what does an attack look like? If you want the full 16 bytes of unpredictability, why don't you just read 16 bytes from /dev/urandom and forget about all the other stuff? Jean-Paul -- http://mail.python.org/mailman/listinfo/python-list
