In presence of malicious adversaries in ideal protocol of Multi Party Computation, how can honest parties get the correct output? i.e., corrupted parties modify their inputs and give to the trusted party. Trusted Party computes the function by taking honest party inputs and modified inputs of corrupted parties which results in a wrong output.
$\begingroup$
$\endgroup$
3
-
$\begingroup$ Are you assuming honest majority? Also, what do you mean by modified inputs? For example, if the malicious party's input is $5$ and they instead send $0$? There isn't anything you can do in that case. $\endgroup$– mikeazoCommented Jul 15, 2015 at 11:43
-
$\begingroup$ Assume honest majority.In example, malicious party send 0 instead of 5. In that case, trusted party computes the function using 0 as one of the input which results in wrong output.Trusted party sends the output(wrong) to honest party i.e., it violates the correctness property of MPC. $\endgroup$– preethiCommented Jul 16, 2015 at 6:04
-
$\begingroup$ @preethi : $\:$ How does that violate "the correctness property of MPC"? $\;\;\;\;$ $\endgroup$– user991Commented Jul 16, 2015 at 13:31
Add a comment
|
2 Answers
$\begingroup$
$\endgroup$
If the honest parties have commitments to the malicious parties' inputs or [encapsulations generated by honest parties] of those inputs, then the function can be modified to check those. Otherwise, the value computed by the trusted party "taking honest party inputs
and modified inputs of corrupted parties" by definition results in a correct output.
$\begingroup$
$\endgroup$
The traditional MPC definition of correctness has no notion of correctness on the inputs. The traditional MPC correctness property deals with the output, i.e., the protocol is correct if $y$ where $y=f(x_1,x_2,\dots,x_n)$ is guaranteed to be output. What the $x_1,\dots,x_n$ values are is completely up to the inputting party.
So, if you want to check that the inputs are "correct", first you have to define what "correct" means. If there is one specific value that is "correct", well then, it would seem that the value is no longer private, so why use MPC at all. As Ricky suggests, maybe you have a commitment (or encapsulation) of each party's input that you can check via MPC. How these commitments are generated is another problem. If you don't trust a party to input the right value, how do you trust them to create a commitment of the right value? Another option might be that you have acceptable input ranges (e.g., the value is always greater than 10 and less than 100), that you can check.
In the end, to answer your question, you must first define what "correctness of inputs" means, because MPC does not typically handle this case. Then defining how the ideal protocol handles it is easy.
