Thanks for you reply, Chris. I thought there wouldn't be any which is kind of sad.
On Sun, Jan 18, 2009, Chris Tan <[email protected]> wrote: > > According to the docs, "On a UNIX-like system this will query /dev/ > urandom": > http://docs.python.org/library/os.html Sure. The question is what kernel do they run there and whether it is configured carefully to avoid RNG-related weaknesses. Is it Linux 2.6.x? Does it have enough entropy just after reboot? Can it under any circumstances revert the RNG to some previous state (e.g., after restoring from a backup)? Or was os.urandom() manually altered for App Engine to use some Google-specific random number generator? > These libraries may also be of interest to you: > http://docs.python.org/library/crypto.html I'm not sure I get how HMAC and the hash functions are related to this. Do you mean some specific way to generate random numbers with them? > http://docs.python.org/library/random.html (See below.) > http://docs.python.org/library/uuid.html The docs don't specify how exactly does uuid.uuid4() generate a random UUID. The source code tries to call some C library function that I'm not sure where to look for (and if that function does not exist, uuid4() just uses os.urandom()). In that light, sticking to os.urandom() seems safer. > Personally, I'm using random.random() for CSRF tokens and it works > great. I'm curious, what kind of application are you developing that > requires this level of security? How do you know when it stops working great and starts being exploited? random.random() uses Mersenne Twister which is not cryptographically strong. If you are just using the value returned by random.random() as your secret token or session cookie, it should be possible for an attacker to predict future secret tokens by observing a sufficiently large sample of generated random values. According to what I read, a sample on the order of 1000 values may be enough. [1] Switching to random.SystemRandom which uses os.urandom() would be wiser, but that method still depends on the security of App Engine's os.urandom(). -- Alexander [1] See section 1.6 ("Limitation and hints for use") of the original paper by M. Matsumoto and T. Nishimura "Mersenne Twister: A 623-dimensionally equidistributed uniform pseudorandom number generator". http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/ARTICLES/mt.pdf For an estimate of the required sample size, see "A Cryptographic Compendium" by J. Savard, section "The Mersenne Twister" <http://www.quadibloc.com/crypto/co4814.htm>, subsection called "Applications to Cryptography". He writes: "Despite the fact that the Mersenne Twister is an extremely good pseudo-random number generator, it is not cryptographically secure by itself for a very simple reason. It is possible to determine all future states of the generator from the state the generator has at any given time, and either 624 32-bit outputs, or 19,937 one-bit outputs are sufficient to provide that state." --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
