The problem is that a hand written python hash function not likely outperform secure hash function implemented in c. This kind attack actually happened once on amazon's s3 service, which caused about 2 hours partial service interruption.
On Oct 2, 4:43 pm, Tony Arkles <[EMAIL PROTECTED]> wrote: > I don't think a *secure* hash function is necessary here (nor do I > think it desirable, due to speed). By the pigeonhole principle, *all* > hashes have collisions; it's just a matter of a) how likely it is to > happen, and b) how much of an impact will it have. > > For doing a hashtable implementation (which is basically what we're > talking about here), it seems to me that it's much more important to > have a fast hash than it is to have a secure hash. In theory an > attacker could submit a huge pile of specially-constructed URLs that > all had the same hash (such that the lookups would be linear instead > of constant), but I'm much more concerned about minimizing my CPU > burder on all requests :) > > On Oct 2, 1:09 pm, yejun <[EMAIL PROTECTED]> wrote: > > > On Oct 2, 2:31 pm, Bill <[EMAIL PROTECTED]> wrote: > > > > Seems like the SHA hashes are overkill. > > > Collisions have been found for both sha0 and md5. > > I guess the minimal usable hash function is sha1 for now. In python > > hashlib uses openssl which should be reasonable fast. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
