Encrypted search?

[Peter Wayner]

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/)