Download Crytography Secure Two-Party Computation, Lecture Notes - Computer Science and more Study notes Cryptography and System Security in PDF only on Docsity!
CS 120/ E-177: Introduction to Cryptography
Salil Vadhan and Alon Rosen Dec. 12, 2006
Lecture Notes 19 (expanded):
Secure Two-Party Computation
Recommended Reading.
- Goldreich Volume II 7.2.2, 7.3.2, 7.3.3.
1 A Tale of Two Lovers
Alice and Bob would like to determine whether they love each other. However, Alice is afraid to reveal her love to Bob only to nd out that he actually doesn't love her. Bob is afraid of the very same thing. They decide to run a cryptographic protocol. Alice holds an input bit a ∈ { 0 , 1 } representing whether she loves Bob (a = 1) or not (a = 0). Bob holds an input bit b representing whether he loves Alice or not. Their goal is to somehow determine whether both a = 1 and b = 1. In other words, they wish to jointly compute the function
f (a, b) = a ∧ b.
The ideal thing for them would be a protocol that reveals the value of f (a, b) to both of them, but does not reveal any more information on their respective inputs than what is necessary." Clearly, having Alice and Bob send each other their inputs on the clear is not a good idea (what if f (a, b) = a ⊕ b?). However, it is not at all clear how to do this in a dierent way. In this lecture, we will see that, somewhat surprisingly, cryptography enables a solution to Alice and Bob's problem. In fact, it will yield a solution to a more general (and challenging!) prob- lem. Under appropriate complexity assumptions, it is possible to securely compute any e ciently computable two-party function f (a, b) (where a, b are not necessarily bits).
2 De ning Security
Before they even attempt to design a solution, Alice and Bob have to de ne what it means for a protocol to be secure." So they decide to start by listing security properties that they would like the protocol to satisfy:
Correctness. If both Alice and Bob follow the protocol's instructions, then their "local" outputs should equal f (a, b). Privacy. The protocol reveals no information to Alice beyond what is revealed by f (a, b) (same for Bob), For example if f (a, b) = a ∧ b and a = 0 then f (a, b) = 0 regardless of the value of b, and the protocol's execution should not enable Alice to tell whether b = 0 or b = 1. Input independence. Alice's input to the protocol should not depend on Bob's input (same for Bob). This is closely related to Privacy. For example, Alice should not be able to set her input a to be equal to b. This is because in such a case Alice will be able to look at the output of the protocol (e.g. f (a, b) = a ∧ b) and learn the value of Bob's input (why?).
These properties are very desirable in many protocol settings and make sense also if more than two parties are participating. For example, in an "electronic voting" protocol privacy should guarantee that, modulo the outcome of the election, my vote is not revealed. Another example would be a protocol for contract bidding where the inputs to the protocol correspond to, say the bids of the individual bidders. In this case, not only privacy might be important but also input independence seems to be a crucial property.
2.1 Semi-Honest Adversaries
In this lecture we will focus on semi-honest adversaries. These are adversaries that faithfully follow the protocol's prescribed instructions, but nevertheless try to learn something from the protocol's execution (by keeping a record of all their intermediate computations). Even though it sounds rather weak, the semi-honest model is of great interest by itself and designing protocols that withstand attacks of a semi-honest adversary is already a non-trivial task. (Notice that having the parties send their inputs on the clear would not yield a secure protocol even against semi-honest adversaries.) The treatment of the semi-honest case will be justi ed in the next lecture, where we will see how to transform any protocol that is secure against semi-honest adversaries into a protocol that withstands arbitrary malicious deviations from the protocol's instructions.
2.2 Security Against Semi-Honest Adversaries
We consider a two party protocol (A, B). The protocol consists of two parties that exchange messages in alternating turns. The messages are determined by the parties' (private) inputs and coin-tosses, as well as on the previous messages that they have received. We will say that a protocol (A, B) computes a function f (a, b) if whenever both A and B follow the protocol's instructions, on inputs a and b respectively, then their local outputs equal f (a, b) A party's view of a protocol's execution consists of its input, coin-tosses, and received messages. We let VIEW( AA,B )(a, b, 1 n) denote a random variable that is distributed according to A's view when the parties' inputs are a, b respectively, the security parameter is n, and the coin tosses of both parties are chosen uniformly at random. B's view is symmetrically de ned. One could think of the view of a party as the information" that this party is obtaining from the protocol's execution. A semi-honest adversary may apply an arbitrary polynomial time program to the view (this corresponds to the distinguisher). Our de nition of security will require that whatever can be (e ciently) obtained from a party's view could be essentially obtained from the input and output available to that party. This is formalized by exhibiting the existence of a probabilistic polynomial time machine (simulator) that, given only the input and output available to the party, is able to produce views that are essentially identical to that party's views in actual protocol executions.
De nition 1 Let f (a, b) be a (deterministic) two-input function. A two-party protocol (A, B) for computing f is said to be secure if there exists PPT algorithms ("simulators") SA and SB such that for any a, b (^) { SA(a, f (a, b), 1 n)
n∈N
c ≡
VIEW( AA,B )(a, b, 1 n)
n∈N { SB (b, f (a, b), 1 n)
n∈N
c ≡
VIEW( BA,B )(a, b, 1 n)
n∈N
where c ≡ denotes computational indistinguishability.
B: Use x = xc = f (^) k− 1 (yc) to compute sc = bk(xc) ⊕ zc.
The above protocol can be also generalized to work for OT1 for any small (e.g. constant) ∈ N (i.e., where Alice holds k values s 1 ,... , sand Bob's choice is an index i ∈ []).
Proposition 2 Suppose that F is a family of trapdoor permutations. Then, (A, B) is a OT^21 protocol against semi-honest adversaries.
Proof Sketch: Consider a machine SA((s 0 , s 1 ), λ, 1 n) that operates as follows:
- Pick (k, t) ←R G(1n) for the trapdoor permutation using coin tosses r.
- Pick two uniformly chosen strings y 0 , y 1 ∈ Dk.
- Output (s 0 , s 1 ), r, (y 0 , y 1 ).
Note that the strings y 0 , y 1 that appear in SA's output are identically distributed to strings y 0 , y 1 that are sent by Bob in an actual execution of the protocol (A, B). This is because when Bob is applying fk to a uniformly chosen x ∈ Dk the result is a uniformly chosen y ∈ Dk. Next, consider a machine SB (c, s, 1 n) that acts as follows:
- Pick (k, t) ←R G(1n) for the trapdoor permutation.
- Pick x, y ←R Dk using coin tosses r. Set yc = fk(x) and y 1 −c = y.
- Compute zc = bk(x) ⊕ s and randomly choose z 1 −c.
- Output c, r, (k, (z 0 , z 1 )).
Note that except (z 0 , z 1 ) the output of SB is distributed identically to the corresponding part of Bob's view. This holds even if we include zc (which equals bk(x)⊕s both in the actual execution and in the execution of SB ). Thus, the only dierence is in the value of z 1 −c. The latter's indistinguishability from the corresponding value in actual executions of the protocol follows from the fact that the function bk() is a hard-core predicate for the family F.
3.2 Using OT for Computing AND
Given a protocol for OT^21 , the task of computing the function f (a, b) = a ∧ b becomes simple. Suppose Alice has input a and Bob has input b. To compute f (a, b) = a ∧ b we let them run the OT^21 protocol with Alice as the sender and Bob as the receiver in the following way:
A: Set (s 0 , s 1 ) = (0, a).
B: Set c = b.
A ↔ B: Run the OT^21 protocol with ((s 0 , s 1 ), c) as input. Bob gets the value of sc as output.
B: send sc to Alice.
A, B: output sc as the result of the protocol for computing f (a, b).
It can be seen that sc = 1 if and only if a = b = 1. Thus, the protocol indeed computes f (a, b) = a∧b.
Claim 3 Suppose that the OT is secure. Then, protocol (A, B) securely computes f (a, b) = a ∧ b.
4 Computing an Arbitrary Function
We next sketch the construction of a secure two-party protocol for computing an arbitrary f (a, b).
4.1 Computing Functions with Boolean Circuits
A Boolean Circuit is a DAG whose edges (wires) are labeled with a value in { 0 , 1 }, and whose nodes (gates) correspond to Boolean operations (e.g. AND, OR, NOT). We may assume without loss of generality that nodes in the circuit have maximal in-degree 2. The computation takes place in the natural way, where for each gate we label its outgoing wire(s) with the value that corresponds to the output of the gate function when applied to the { 0 , 1 } values with which the two incoming wires are labeled. For example if the gate corresponds to the AND function and its incoming wires are labeled with ai, bi respectively then its outgoing wire(s) will be labeled with the value of ai ∧ bi. The inputs a, b of the function correspond to the value of input wires (which are sources" in the DAG). The inputs a, b are viewed as bit strings and each wire corresponds to one bit of input. The output of the function corresponds to certain output wires (which are sinks in the DAG) and equals the value these wires are labeled with.
Fact 4 Any polynomial time computable function f (a, b) can be computed by a polynomial size Boolean Circuit with only AND and NOT gates.
4.2 Computing with Shared Inputs
Alice and Bob hold inputs a^1 ,... , an^ and b^1 ,... , bn^ respectively, where ai, bi^ are bits. They wish to jointly compute the function f ((a^1 ,... , an), (b^1 ,... , bn)). To do so, they start by exchanging "shares" of each of their input bits ai^ and bi. Thus is done in the following way. Suppose that Alice would like to share an input bit a and Bob would like to share an input bit b:
A → B: Pick a 1 ← {R 0 , 1 } and set a 2 = a ⊕ a 1. Send a 2 to Bob.
B → A: Pick b 2 ← {R 0 , 1 } and set b 1 = b ⊕ b 2. Send b 1 to Alice.
Note that a 1 ⊕ a 2 = a and b 1 ⊕ b 2 = b so a 1 , a 2 can be thought of shares of a and b 1 , b 2 can be though of shares of b. Also note that following the above process we have:
- Alice holds shares a 1 , b 1 of a and b respectively.
- Bob holds shares a 2 , b 2 of a and b respectively.
- Neither a 1 or a 2 individually reveal any information about a.
- Neither b 1 or b 2 individually reveal any information about b.
Alice and Bob repeat this process for every one of their input bits ai^ and bi. As a consequence, they both hold shares for all of the circuit's input wires. Their objective is, given shares of the form a 1 , b 1 and a 2 , b 2 for two wires that enter a certain gate, to jointly compute shares for the label of the corresponding output wire(s). If they can do this for any given gate, they can eventually go through all the gates of the circuit (one by one) while computing new shares for all intermediate wires.
