At 10:11 AM +0100 9/22/03, Dave Howe wrote:
Tyler Durden wrote:
When the search is performed, the "stupid" thing to do (I think...someone correct me) is to take the user's ID, encrypt it, and then determine if matches an encypted member of the list (and I don't see encrypted each entry individually as a desirable thing). I am assuming that this allows a savvy user to reverse-engineer the encryption. What you do is hash the ID, then compare it to the list of hashed entries, using the ID as the key to decrypt the data associated with that entry while that isn't subject to reverse engineering, the abuse it *is* open to is random guessing of IDs (every "success" gives someone else's record, with failures having no penalty) Adding a password (and combining it with the ID to give your key) will address some of that, but really you need to encrypt each entry individually to prevent someone simply decompiling your code and obtaining your full data list.
Another option is one I don't have the background at this stage to understand. Let's assume the entire list has been encrypted in one shot. Is there some function such that when this encrypted list is convolved with the user ID a "Yes" or "no" can be obtained (indicating presence or absence from the list)? no. if you trial encrypt the sample ID for comparison, you hand them the key to the whole list.
Yes, these are all good solutions. If you want a case study of how this might help a company like Amazon, go here: http://www.wayner.org/books/td/u1.php --------------------------------------- My new books: _Policing Online Games_ (http://www.wayner.org/books/pog/) _Java RAMBO Manifesto_ (http://www.wayner.org/books/rambo/)