Introduction to Modern Cryptography, Lecture 12

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

2. 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

3. 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))

4. 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 1n)

5. 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

6. 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

7. 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

8. 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)

9. 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

10. 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

11. Required Gates

12. Addition Gate c1 = a1+b1 c2 = a2+b2 c1+c2 = a1+a2+b1+b2

13. Multiplication Gate c1+c2 = (a1+a2)(b1+b2) (c1,c2) should be uniformly chosen amongst all solutions We use Oblivious Transfer

14. Oblivious transfer in the case of semi-honest parties • Sender has t1, t2, …, tk (bits) • Receiver chooses some 1 ≤ i ≤ k • Goal: Receiver gets ti, Sender does not know i

15. OT Using RSA for semi-honest • Sender chooses RSA keys, sends public key to Receiver • Receiver chooses random e1, e2, …, ek • Receiver computes RSApub(ei) • Receiver sends Sender: • Sender computes:

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

17. Privately computing c1+c2=(a1+a2)(b1+b2) • We use Oblivious transfer with four shares • Party 1 chooses a random c1 in 0,1 • Party 1 has a1, b1, and plays the OT sender with • Party 2 has a2, b2, and plays the OT receiver with

18. Correctness

19. 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

20. 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.

21. 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

22. 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

23. 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

24. Alice does not want Bob to know her coin tosses, only to prove that they are honest: • Alice chooses many random bits b1, b2, …and sends Bob the bit commitments • Bob sends Alice random bits c1, c2, … • Alice uses the bits bi + ci 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

25. 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