0

I am trying to design a pairing application for my university this valentine. How is it supposed to work, you ask?? The clients will submit preferences specifically names to the server and after some days if any two clients have the same preferences, they will be notified -- not in any other case. A fool-proof framework design needs to be built for this purpose. What I am willing to do is to ensure my clients that even though they will be submitting their favourite responses to me via my website, I will still not be able to see those as if I would, this application will have issues of privacy. I am trying to match the user preferences with each other, they will obviously be encrypted and there is no way I can match any two unless I decrypt them at some point in my server locally -- assuming the fact that RSA encryption mechanism has a very little probability of collision of hashed values and I definitely cannot match them :) . The bottleneck here then is >> never ever decrypt the client preferences locally on the admin's machine/server. One approach which is currently on my mind is to introduce a salt while encrypting which will stay safe in the hands of the client, but still decryption needs to be done at some point in time to match these hashes. Can there be some alternative approach for this type of design, I think I might be missing something.

Improve this question

2 Answers 2

Reset to default
5

I will assume that clients answer a series of n boolean questions. The server stores their answers in such a way that you that admin can not know their responses. Then the server identifies pairs of clients with identical responses.

Then could not you the admin (or anyone really) create 2^n dummy accounts (all possible responses to the boolean questions). The server forms pairs. Now you know everyone's responses.

So I do not think this is possible. (Did I miss something?)

Improve this answer
4
  • I am willing that instead of answering a boolean question, the client will simply enter the name of the person of his/her choice. I guess if this could be translated into a boolean question then the admin will certainly not know their responses, but I think this is not the case here.
    – yellowflash
    Feb 12, 2016 at 1:39
  • Plus also if the clients are supposed to submit boolean responses, their is an additional overhead required from the admin's side which he/she will expend in computing as you said by constructing 2^n cases. This approach is better than the trivial approach that I suggested. But sadly, we cannot use boolean questions in my case.
    – yellowflash
    Feb 12, 2016 at 2:45
  • @ShivanshRai Please update your question to include the fact that it is names you are matching.
    – Anders
    Feb 12, 2016 at 10:00
  • 1
    @ShivanshRai I suggest you look at en.wikipedia.org/wiki/Secure_multi-party_computation. There might be a way. It would probably be sufficiently complicated that no one would actually use your application.
    – emory
    Feb 12, 2016 at 14:08
1

I'm not a security expert but my reasoning is the following: If you encrypt the information using shared key (known to you) then you can decrypt data on server and compare it. If you encrypt data on the clients using individual keys you can not decrypt the data but you cannot compare them.

I see two solutions

  • Simple - hash the data (using shared secret) - if you get identical hash for two entries this means the original data was the same (with very high probability) or there was hash collision (with very low probability). You can try to guess somebody-s answer and check it but this is in essence functionality of your application (matching two responses) and is impossible to avoid.

  • Complex - find encryption that have property that:

    For given clear-text c and two secrets s1 and s2 encryption e it is true that e(e(c,s1),s2) = e(e(c,s2),s1) (I'm sure there is a proper name for this property but I do not remember it now)

    now everybody encrypt their secret preferences with their own secret key, then they encrypt everyone else preferences with their secret key - if you get identical ciphertext for a pair then the original preferences were the same. This still do not prevent you from trying to guess answers but make it impossible to do it offline without "victim" cooperation (they have to encrypt every your guess with their secret key).

Now in both cases I would think about normalizing the answers to prevent mismatch caused by slightly different input, so you can for example trim the white space, make case uniform and remove some special characters before encryption / hashing.

One more things - regardless of the method users still have to trust you (to input the data on your web page or to install your application), to believe that you do not have malicious intent and implemented the privacy scheme correctly. So even if you come up and implement a good scheme the trust still can be a problem.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .