On Jan 18, 5:54 am, "Alexander Konovalenko" <[email protected]> wrote: > Thanks for you reply, Chris. I thought there wouldn't be any which is > kind of sad. >
No problem. I thought it was an interesting question :) > 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? > That's a question only the Google employees can answer. > > 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? > My apologies, I hadn't looked over it carefully. > >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. > The docs mention that the functions follow the RFC 4122 (http:// rfc.net/rfc4122.html) guidelines for generating UUIDs. The site is down right now, but you might be able to find a google cache of it. > > 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." It's actually even weaker than that. A man in the middle attacker (e.g. a wifi provider) wouldn't even need to predict the next token; sniffing the current token and inserting a script tag into the next page the user requests would work perfectly (I'm using the cookie method). That being said, the level of security being employed should be dependent on the application. I feel that my app is "secure enough", and in the unlikely situation that someone is knowledgeable and motivated enough to compromise it, I still have backups. Rolling your own security can be a big time sink when frameworks such as Django do it well by default. If you are starting to worry about your crypto being broken, maybe appengine isn't the right platform. Google employees are only human, and who knows when one of them will be pulled to the "dark side" =P Thanks for the reply Alex, it was very informative. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
