Introduction to Modern Cryptography, Lecture 12 Secure Multi-Party Computation

We want to emulate a trusted party Imagine that the parties send their inputs to a trusted party (no eavesdroping) The trusted party computes the “ functional ” (not a function): a random process that maps m inputs to m outputs The trusted party gives every party its output (again no eavesdroping) We want to do without a trusted party

General Two-Party Computation A 2 party protocol problem is a random process that maps pairs of inputs (one per party) to pairs of outputs Special cases of interest: f(x,y) = (g(x,y),g(x,y)) f(x,y) = uniformly distributed over ((0,0),(1,1))

Conventions The protocol problem has to be solved only for inputs of the same length The functionality is computable in time polynomial in the length of the input Security is measured in terms of the length of the input (use inputs 1 n )

The semi-honest model A semi-honest party is one who follows the protocol with the exception that it keeps all its intermediate computations –In particular, when the protocol calls for tossing a fair coin, the semi-honest party will indeed toss a fair coin –Also, the semi-honest party will send all messages as instructed by the protocol Actually, it suffices to keep the internal coin tosses and all messages received

Privacy in the semi-honest model A protocol privately computes if whatever a semi-honest party can obtain after participating in the protocol, it could obtain from its input and output

Security in the semi-honest model The “ ideal ” execution makes use of a trusted third party A semi-honest protocol is secure if the results of the protocol can be simulated in the ideal model In the semi-honest model, security = privacy

The Malicious Model There are three things we cannot hope to avoid: –Parties refusing to participate –Parties substituting their local input –Parties aborting the protocol prematurely Security in the malicious model: the protocol emulates the ideal model (with a trusted third party)

Secure Protocols for the Semi- Honest model Produce a Boolean circuit representing the functionality Use a “ circuit evaluation protocol ” which scans the circuit from the inputs wires to the output wires When entering a basic step, the parties hold shares of the values of the input wires, and when exiting a basic step, the parties hold shares of the output wires NOTE: ONLY DETERMINISTIC SO FAR

What gates? It suffices to consider AND and XOR gates of fan-in 2 Use arithmetic over GF(2) where multiplication = AND and addition = XOR –1*1=1, 1*0=0, 0*0=0, 0*1=0 –1+1=0, 1+0=1, 0+1=1, 0+0=0

Required Gates

Addition Gate c 1 = a 1 +b 1 c 2 = a 2 +b 2 c 1 +c 2 = a 1 +a 2 +b 1 +b 2

Multiplication Gate c 1 +c 2 = (a 1 +a 2 )(b 1 +b 2 ) (c 1,c 2 ) should be uniformly chosen amongst all solutions We use Oblivious Transfer

Composition Theorem for the semi- honest model, two parties Formally: an oracle computation is one where one can access an oracle to get a result An oracle-aided protocol is said to be using the oracle-functionality f if the oracle answers according to f An oracle-aided protocol is said to privately reduce g to f, if it privately computes g when using the oracle functionality f Theorem: Suppose that g is privately reducible to f and that their exists a protocol for privately computing f, then there exists a protocol for privately computing g

Reducing private computation of general functionalities to deterministic functionalities

Oblivious transfer in the case of semi-honest parties Sender has t 1, t 2, …, t k (bits) Receiver chooses some 1 ≤ i ≤ k Goal: Receiver gets t i, Sender does not know i

OT Using RSA for semi-honest Sender chooses RSA keys, sends public key to Receiver Receiver chooses random e 1, e 2, …, e k Receiver computes RSA pub (e i ) Receiver sends Sender: Sender computes:

OT Using RSA for semi-honest Sender sends Receiver: Receiver computes:

Privately computing c 1 +c 2 =(a 1 +a 2 )(b 1 +b 2 ) We use Oblivious transfer with four shares Party 1 chooses a random c 1 in 0,1 Party 1 has a 1, b 1, and plays the OT sender with Party 2 has a 2, b 2, and plays the OT receiver with

Correctness (1,1)(1,0)(0,1)(0,0)(a2,b2)(a2,b2) 4321i = 1 + 2a 2 + b 2 c 1 + (b 1 +1)(a 1 +1) c 1 +b 1 (a 1 +1)c 1 +a 1 (b 1 +1)c1+a1b1c1+a1b1 Output

The circuit evaluation protocol Do a topological sort of all wires in the circuit Input wires: every player “ shares ” the value of her input wire with the other player Once the shares of the circuit output wires are computed, every party sends its share of wires for the other party

How to force semi-honest behavior Theorem: suppose that trapdoor permutations exist (e.g., RSA), then any two party functionality can be securely computable in the MALICIOUS MODEL.

Problems with Malicious parties Different input (nothing to do) Does not use truly random bits (I happen to have chosen at random the ace) – use coin tossing in a well Send messages other than the messages it should send via the protocol – use zero knowledge proofs

Coin tossing in a well A coin tossing in a well protocol is a two party protocol for securely computing (in the malicious model) the randomized functionality Where b is uniformly distributed on 0,1

Simple solution Use an encoding of 0 ’ s and 1 ’ s Alice chooses a random encoding of a random bit b and sends Bob the one- way function (or more exactly bit commitment) of the bit Bob sends a random bit c to Alice Alice reveals the commitment to b The common random bit is b+c

Alice does not want Bob to know her coin tosses, only to prove that they are honest: Alice chooses many random bits b 1, b 2, … and sends Bob the bit commitments Bob sends Alice random bits c 1, c 2, … Alice uses the bits b i + c i in her computation Alice gives Bob a zero knowledge proof that the computation uses these bits, based upon the commitments to the bits that Bob already has

Alice ’ s other inputs Alice needs to be consistent in her inputs, we cannot force Alice not to lie about her input, but at least we can force her to be consistent