CSE208: Advanced cryptography, Fall 2002

Lecture 11: Secure multiparty computation

2-party private protocols

Last time we showed that, using a private protocol for OT, one can build private protocols for any function f. We also showed that the private OT protocol based on trapdoor permutations can be transformed into a secure protocol using ZKPK techniques. A natural question arise: if we use a secure OT protocol in the construction of the protocol for f, do we get a secure protocol? It is easy to see that the answer is NO. Security of the underlying OT protocol does not guarantee the security of the entire construction. The reason is that the definition of security allows the adversary to substitute the inputs for every invocation of OT. These inputs correspond to intermediate computations of protocol f, and the security definition of f only allows to substitute the initial input to f, but not intermediate messages, which would affect the correctness of the protocol.

Still, in this lecture we will show that using essentially the same techniques used to make OT secure, one can make any private protocol secure agains general adversaries. In order to do this in a general setting, we will formulate these techniques as secure function evaluation problems, and then use them in our construction using the composition theorem for secure protocols.

Below, we recall the definition of private protocols, which is our starting point. For simplicity we first consider 2 party protocols.

A private 2-party protocol is specified by two polynomial time computable functions P[1] and P[2]. Let x[1,2] and r[1,2] be the inputs and the randomness of the two parties. The two parties alternate exchanging messages, with m[i,1],m[i,2],...,m[i,n] the messages sent by party i. We assume that P[1] talks first. The messages are specified by the formulas:

The final output of the two parties are "messages" m[1,n+1] and m[2,n+1] (which are not transmitted.) Let f(x[1,2]) = y[1,2] be the function computed by the protocol. Assuming that the protocol is secure means that there exists two simulators S,S' such that for all inputs x[1,2]

Building blocks

We assume building blocks securely computing the following functions

Input commitment 1: ((x,s),_) -> (_,com(x,s))

Input commitment 2: (_,(x,s)) -> (com(x,s),_)

Random string 1: (s,_) -> (r, com(r,s)) with r chosen at random

Random string 2: (_,s) -> (com(r,s),r)

Authenticated computation 1: ((x,s,r,s',m[1],...,m[i]),(com(x,r),com(b,r')),m[1],...,m[i])) -> (_,P[1](x,r,m[1],...,m[i])

Authenticated computation 2: ((com(x,s),com(r,s'),m[1],...,m[i]),(x,s,r,s',m[1],...,m[i]) ->(P[2](x,r,m[1],...,m[i]),_)

All protocols can be securely implemented using PKZK and commitment schemes.

For example, in the input commitment protocol P1 sends c=com(x,s) to P2, and gives a zero knowledge proof of knowledge of x and s.

Similarly for the authenticated computation protocol.

The random string protocol works by first P1 committing to a random com(r',s'), P2 sends r'' to P1, and P1 computes r = r+r'', sends com(r,s) to P2, and gives a ZKPK of r',s' and s.

Secure 2-party protocol

The construction of the secure protocol should be clear from the building blocks:

Is the protocol secure? We prove it assuming that the building blocks are implemented by a trusted party. Let A be an adversary playing the role of P[1] (the other case is symmetric). The ideal adversary I attacking function f works as follows:

  1. Run A on input x[1],r[1] to obtain x'[1],s[1].
  2. Pass x'[1] to the trusted party to obtain y[1] = f(x'[1],x[2])
  3. Run the simulator for the private protocol S(x'[1],y[1]) to get the view (r[1],m[2,1],...,m[2,n])
  4. Send A com(0,s[2])
  5. Get s'[1] from A
  6. Send r[1] to A
  7. Send com(0,s'[2]) to A
  8. As long as A follows the protocol, send m[2,i] to A
  9. Output the final message produced by A.

The only difference between the simulated interaction and a real execution of the protocol is that at step 4 and 7, A receives commitments to 0 instead of commitments to x[2] and r[2], and the messages m[2,i] are produced by the privacy simulator, instead of running the protocol. It follows from the security of the commitment scheme, and the privacy of the original protocol, that the output of the ideal adversary (joint with y[2]) is indistinguishable from the real attack.

The early termination problem

There is an issue that we overlooked in the description of the previous protocol. If one of the parties is not honest, it might give messages to the authenticated computation protocol that do not respect the syntax, or previous conversation and commitment. In this case, the authenticated computation protocol output a special failure symbol, and the recepient aborts the protocol. There is no way to avoid this problem when half (or more) of the players are faulty. So, in order to accomodate for this kind of failures, we extend the ideal model, giving the ideal adversary the power of interrupting the protocol. It is important to notice that the protocol can be interrupted before contributing input x[1], but also after receiving the output y[1]. I.e., the decision of aborting may depend on the output of the protocol.

The above proof immediately achieves this notion of security, with the ideal adversary aborting the protocol as soon as A contributes a malformed input to the authenticated computation protocol. Also, P[2] will stop responding to P[1] as soon as A is detected cheating, so we do not transmit the remaining messages m[2,i]. The final output of P[2] is the special failure symbol, which is the same as y[2] when P[1] decides to abort.

In class we said that we can always assume that P[1] is the only party with the power of aborting after learning the output. This is easily achieved by encrypting y[2] under a key chosen by P[1]. At the end of the computation P[1] reveals the key to P[2]. This way, if P[2] aborts, he will not receive the key and learn nothing about y[2].

The multiparty case

The previous protocol can be extended to multiparty case as follows.

First, we transform the protocol from point-to-point channels to broadcast channel. Point to point communication can be emulated using a broadcast channels by having each party broadcasting his public encryption key, and everybody sending messages encrypted on the broadcast channel, so that only the intended recepient can read them.

Then, we modify the protocol in a way similar to the 2 party case: first of all, each party committs to its input, then, randomness for each party is generated in a secure way and everybody receives a commitment to the randomness. Finally, each time a party broadcast a message, it gives a zero knowledge proof that the message is the one computed by the protocol.

This results in a protocol that is secure against malicious parties, assuming a broadcast channel. The broadcast channel can be emulated on point-to-point channels using digiral signatures.

We will discuss secure multiparty computation protocols and specific problems like broadcast, later on in the course. In particular we will show that when a strong (2/3) majority of the players are honest, then one can make the protocol also robust against early termination.


O. Goldreich, Secure Multi-Party Computation. manuscript