well, I don't have the mathematical skills to prove you wrong: but according to several articles I've read, MD5 hashes are not collision resistant, and there are several ways to crack an MD5 hash (that are better than brute force)
so: * it's not purely theoretical * the e-mail address could be restored from the hash when you say: "sufficiently random", then why don't we use a simple random number instead of an hash value of the (valuable) user-mail address? the random number would also be "sufficiently random" :) Why don't we simply use the unique user-id instead of the user's mail address for the sharded counter? That would be a perfect fit - it's unique and meaningless Anyway - I don't want to harp on about that. The artice is great, but I think there should at least be a footnote that there might be better ways instead of using MD5-hashes of users mail- addresses On Oct 27, 12:44 am, "Nick Johnson (Google)" <[email protected]> wrote: > Hi Martin, > > MD5 hashes are sufficiently random that collisions are purely theoretical > and not of practical concern. Many systems, for example, address files by > MD5 or SHA1 hash. > > If you can provide an MD5 or SHA1 collision between two short, > human-readable strings, however, I will be happy to amend the article with > this caveat. > > Regards, > > Nick Johnson > > On Sun, Oct 25, 2009 at 5:40 PM, Martin Trummer <[email protected] > > > > > wrote: > > > in this article > >http://code.google.com/intl/de-DE/appengine/articles/paging.html > > the author points out the problems that arise when you use a field > > that may not be unique for paging. > > the solution is to use a sharded counter over the user to make the > > field unique. > > > Very fine until here. > > But then he suggests to use a MD5-hash-value of the unique value > > instead of the real unique value. > > > This is obviously wrong: > > A hash function, will by definition NOT retain the uniqueness of the > > source value! > > > Sure, the chances that 2 unique values result in the same hash value > > is (and should by definition be) very low: > > but we are not satisfied with a "solution" that works most of the > > time, are we? > > -- > Nick Johnson, Developer Programs Engineer, App Engine > Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: > 368047 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
