Generating Unique Keys

Paul Rubin phr-n2003b at NOSPAMnightsong.com
Wed Jan 29 00:57:18 EST 2003


trevp at trevp.net (Trevor Perrin) writes:
> you're right, with normal integers I don't think there's a
> vulnerability, there would only be one if the appended values could
> somehow have a prefix that matched a previous value's SHA1 padding. 
> Still, hmac's cheap and easy, it's a good habit to always use it for
> keyed hashing, so you don't have to worry about this sort of nuance
> (I'm sure you know this, just for anyone following along)..

Yeah, I guess so, there's not exactly a big performance bottleneck to
worry about in this situation.  I think the appending attack is
irrelevant anyway though, since the token is not being used as a MAC.
A token isn't automatically valid just because it was made with the
right key.  It has to belong to an actual session currently active in
the server.

> Sorry for being vague - by a "good random" value I meant one from egd,
> or hardware, or from polling and mixing together a bunch of OS values,
> thread timings, etc..  These "good random" values are usually
> expensive to get or there's not that many of them, so if you needed
> lots of them to use as session identifiers, you'd probably get one
> once for use as a key, then use repeated hashing (your demonstration)
> or ciphering (my demonstration) to get subsequent values, and reseed
> with a "good random" value periodically.

If you can seed a CPRNG with enough physical entropy to make the
initial state unguessable, I'm ok with calling the subsequent output
"good random".

> As for getting these "good random" values on different systems, the
> paper below has a pretty good discussion of the issues involved, and
> the techniques are implemented in cryptlib so you can see what the
> code looks like:
> 
> http://www.cs.auckland.ac.nz/~pgut001/pubs/usenix98.pdf
> http://www.cs.auckland.ac.nz/~pgut001/cryptlib/

You might also look at the Yarrow paper on counterpane.com.  But this
stuff is extremely tricky to get right.  It's better to just use OS
services, which are now provided on most platforms where it matters.
The services are generally based on techniques like the ones in those
papers, and written with an intimate knowledge of the intended
platform.  It's really not practical for Python to directly attempt
that stuff.  




More information about the Python-list mailing list