How good is security via hashing

[Jean-Paul Calderone]

On Jun 7, 6:18 am, Robin Becker <ro... at 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