In class, I showed one natural candidate definition of security for semi-honest 2-party computation, but I warned that it turns out to be not strong enough. Then, I showed a fixed definition. Several folks wanted to know what was wrong with the first attempt at a definition, and I wasn't able to explain in class. This note is intended to explain what's wrong with the first attempt. This is a bit of a footnote; if you just take the correct definition on faith, that's fine by me, but I wanted to give some explanation for those who are interested in the details. Let me remind you of the broken definition: Defn #1: The protocol (A_1, A_2) is secure if there exists a pair of simulators S_1,S_2 so that for all input pairs x_1,x_2, we have (1) correctness: (y_1, y_2) ~ f(x_1, x_2); and, (2) privacy: view_A_1(...) ~ S_1(x_1, y_1) and view_A_2(...) ~ S_2(x_2, y_2). Ok, so that might look reasonable, but it has a flaw. Consider the following functionality: f(-,-) = (b,-) where b <- {0,1} is a random bit. Here is a silly protocol intended to implement this functionality: A_1 picks b <- {0,1} randomly A_1 -> A_2: b A_1 outputs b What do you think of this protocol? Obviously, it satisfies the correctness condition. It also happens to satisfy the privacy condition shown above. For instance, A_2's view can be simulated by a simulator S_2 that takes no inputs, flips a random coin, and outputs it. This is a valid simulator for A_2's view, since A_2's view is a random bit. So if we used the broken definition above, this silly protocol would be considered "secure". But this silly protocol is indeed truly silly. Intuitively, we should be unhappy with it, because A_2 learns the value of A_1's output, something that doesn't happen in the ideal model. Obviously, something is wrong with this protocol, and that means that something is wrong with any definition that considers this silly protocol "secure". That's why Defn #1 above is broken. The fix is as follows: Defn #2: The protocol (A_1, A_2) is secure if there exists a pair of simulators S_1,S_2 so that for all input pairs x_1,x_2, we have (1) correctness: (y_1, y_2) ~ f(x_1, x_2); and, (2') privacy': (view_A_1(...), y_2) ~ (S_1(x_1, y_1), y_2) and (view_A_2(...), y_1) ~ (S_2(x_2, y_2), y_1). Note that our revised definition will not accept the silly protocol as "secure". A_2's view is the bit b; also, A_1's output y_1 is this same bit b. Therefore, if we look at the second part of the privacy' condition, it would require that (b,b) ~ (S_2(-),b). But there is no way to construct a simulator S_2 that can generate outputs of the required distribution: intuitively, S_2 doesn't know b, so it can't output the required value. Maybe this example illustrates why the revised definition is needed. What went wrong in the silly protocol is that A_2's view was correlated to A_1's output. Defn #2 captures the idea that A_2 learns nothing about A_1's output y_1, because it requires that if there is any correlation between A_2's view and y_1, then the simulator S_2 can generate outputs that are correlated in exactly the same way with y_1. Defn #1 didn't require that S_2's outputs be correlated with y_1 in the same way that A_2's view is correlated with y_1, and that's why Defn #1 is unsatisfactory. Actually, as a footnote, I should mention that Defn #1 and Defn #2 seem to be equivalent if the functionality f is a deterministic function. It's just when f is randomized that you can get into trouble with Defn #1. If you were willing to restrict yourself to deterministic functionalities, Defn #1 would be a perfectly reasonable definition. Of course, in practice randomized functionalities are very natural, and that's why we need Defn #2. If you followed so far, here is a simple exercise to test whether you grok this at a deep level. Question: To prevent A_2 from learning a value that is correlated somehow to y_1, we added y_1 to the distribution under consideration. But we would also like to prevent A_2 from learning anything that is correlated somehow to x_1. Do we need to add x_1 to the distribution under consideration, too? Do we need a Defn #3? Answer (ROT13 encrypted): Ab. Gur pbaqvgvbaf ner erdhverq gb ubyq sbe nyy k_1,k_2, urapr k_1 vf svkrq. Vg qbrfa'g znxr frafr gb gnyx nobhg orvat pbeeryngrq gb n svkrq inyhr; vs gurer vf nal yrnxntr bs vasbezngvba nobhg k_1 cerfrag va N_2'f ivrj, gung yrnxntr vf nyernql pncgherq ol gur cebonovyvgl qvfgevohgvba bs ivrj_N_2(...). Fb Qrsa #2 vf whfg svar. Also, for reference, I will write out the generalization of the above definition to security for k-party parties, in the semi-honest model: Defn: The protocol (A_1, .., A_k) is secure if (1) correctness: for all k-tuples x_1,..,x_k, we have (y_1, .., y_k) ~ f(x_1, .., x_k); and, (2') privacy': for each non-trivial subset I of {1,..,k}, there exists a simulator S_I, so that for all k-tuples x_1,..,x_k, we have (view_A_I(...), y_J) ~ (S_I(x_I, y_I), y_J). Here J = {1,..,k} \ I denotes the complement of I; x_I is the concatenation of values x_i for i in I; view_A_I(...) is the concatenation of the views of the parties A_i for i in I; etc. This is a straightforward extension of Defn #2 above.