1

I am trying to build a system that would allow information sharing in a kind of zero-knowledge way. Here is the set up:

  1. Let's say there is a trusted third party that has Alice's sensitive info M (e.g. date of birth). This 3rd party encrypts M, so C = E(M, a) where a is a secret key. After that, the 3rd party makes C public (e.g.publishes on their website). Also, the 3rd party shares a with Alice.
  2. Alice would like to give her DOB to Bob, but in such a way that Bob would not be able to give her DOB to anyone else.

This can be achieved using an interactive zero-knowledge system that would work like so:

Assume E is an encryption function and U is a decryption function, such that:

  1. C = E(M, a), where a is a secret key
  2. X = E(C, b), where b is another secret key
  3. M = U(C, a) and C = U(X, b) - basically, the keys can be used to decrypt the values they encrypted
  4. M = U(X, ab), where ab is some way of combining both keys together so that separating ab into a and b is impractical

With this setup, Alice can generate a random key b1 and compute X = E(C, b1). She can then give X to Bob, who in turn would ask Alice to reveal one of the following:

  1. b1 - this would allow Bob to verify that X was derived from C because C = U(X, b1)
  2. ab1 - this would give Bob Alice's DOB because M = U(X, ab1)

They repeat this process but now with new secret keys b2, b3 ... bn until Bob is satisfied with the level of confidence. At the end, Bob will know Alice's DOB, but he wouldn't be able to prove to anyone that this is in fact her DOB.

My Questions are:

  1. Is there a better way to share info between Alice and Bob in such a way that Bob can be sure he has Alice's correct DOB, but he wouldn't be able to prove it to anyone else?
  2. If this is the best way, what is the right encryption/decryption function to use so that you can combine 2 keys together in the way described above?
irakliy
  • 969
  • 7
  • 16
  • Here's an alternative protocol. Alice and Bob agree on an authenticated shared secret, and Alice sends Bob her DOB with a symmetric authenticator that does not admit third-party verification (i.e., not a signature). Then Bob knows her DOB, but he has no cryptographic attestation he can show to anyone else to verify. – Squeamish Ossifrage Apr 07 '18 at 16:32
  • What do you need Bob to be able to do with the DOB? If Bob ever learns the actual value for an arbitrary computation, then he can leak it to Cambridge Analytica with wild abandon. But if there's some specific computation that Bob needs to perform, maybe there's something he can do to perform that computation without learning the DOB at all. – Squeamish Ossifrage Apr 07 '18 at 16:33
  • This is a "general purpose" system. So, there could be variety of reasons why Bob would need Alice's DOB (and other PII). It could be to check legal age, or use it for a loan application, or anything else. I am not sure I followed the alternative protocol: how would Bob verify that Alice didn't lie and didn't send him fictitious DOB? – irakliy Apr 07 '18 at 16:43
  • I see: you want to make sure Alice gives everyone the same DOB, when she wants them to learn her DOB, and enable whoever she's authorized to verify that it is the same as everyone else would see, but without letting them enable anyone else to verify it? – Squeamish Ossifrage Apr 07 '18 at 16:49
  • Yes - this is exactly correct. By the end of the exchange Bob should be sure that the DOB Alice gave him is valid (has been verified by a 3rd-party authority), but he should not be able prove to anyone else that this is in fact Alice's DOB. – irakliy Apr 07 '18 at 16:52
  • This protocol is essentially proving 'I know the key $k$ for which $E_k(M) = C$'. Question: is it essential that $E$ be efficiently invertible? If not, then it would appear that a Pedersen commitment would be able to do it more efficiently; commitment is $G^M H^k$; proof (which you send along with $M$) is an interactive Schnorr proof that you know $k$ (one exchange, as opposed to the $n$ exchanges you need with your cut-and-choose approach) – poncho Apr 20 '19 at 14:12

0 Answers0