Tyler Durden wrote:
Let's say I push out a list I'd like to keep secret to some client machine. The user of that machine must enter some ID or other piece of information. I want the client machine to perform a search of that ID vs the contents of a list (again, resident locally on that machine), but I don't want the user to be able to see the other entries of that list.
[...]
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.
This is, roughly, how traditional Unix password security works. Reverse-engineering the encryption may or may not be possible, and ought not to matter if you have used a strong enough method and long enough keys. And anyway, if this is running on the client machine then they already have a program that can do the work. What is possible is brute-forcing by encrypting the whole dictionary and trying every word one by one. If your algorithm is strong enough, your key long enough, and above all if the space from which the plaintext is taken is large enough, than this sort of approach can be made sort of safe enough for most applications. But why bother?