Round-Efficient Multi-Party Computation in Point-to-Point Networks

1. Round-Efficient Multi-Party Computation in Point-to-Point Networks Jonathan Katz Chiu-Yuen Koo University of Maryland

2. Round-Efficient Multi-Party Computation in Point-to-Point Networks Jonathan Katz Chiu-Yuen Koo University of Maryland

3. Motivation • Suppose we want to obtain a practical protocol for a given task • The protocol needs to be round-efficient • If we know round-efficient solutions exist, we can then turn our attention to improving other aspects (such as computation)

4. Motivation • Suppose we want to obtain a practical protocol for a given task • The protocol needs to be round-efficient • If we know round-efficient solutions exist, we can then turn our attention to improving other aspects (such as computation) • How do we know?

5. Motivation • Approach 1: • Determine whether round-efficient solutions are possible after we are given the task • Given task A, ask if round-efficient solutions for task A exist • Given task B, ask if round-efficient solutions for task B exist • Given task C, ask if round-efficient solutions for task C exist • …………………………………………………… • Repetitive! • Can we solve the problem once and for all?

6. Motivation • Approach 2: • Determine whether round-efficient solutions for secure multi-party computation (MPC) exist • A MPC protocol can solve almost every task • A round-efficient solution for MPC implies the existence of round-efficient solutions for (almost) every task!

7. Round-Efficient Multi-Party Computation in Point-to-Point Networks

8. Round-Efficient Multi-Party Computation in Point-to-Point Networks

9. Our Motivation • Previous work on round complexity (for the most part) has assumed a broadcast channel “for free” • A broadcast channel enables one party to send the same message to all parties • But in point-to-point networks, a broadcast channel does not come for free; it is emulated by a broadcast protocol • High overhead

10. Our Motivation • Previous work on round complexity (for the most part) has assumed a broadcast channel “for free” • A broadcast channel enables one party to send the same message to all parties • But in point-to-point networks, a broadcast channel does not come for free; it is emulated by a broadcast protocol • High overhead

11. Our Motivation • If the broadcast channel is emulated by a deterministic protocol, then the round complexity will be linear in the number of corrupted parties [FL82] • This will not lead to sub-linear-round protocols

12. Our Motivation • If the broadcast channel is emulated by arandomized protocol, then each round of broadcast can be emulated in an expected constant number of rounds (assuming honest majority) [FM88, FG03, KK06] • But the exact constant is rather high • If broadcast is used in more than one round, then we need to handle sequential composition of protocols without simultaneous termination — leads to complication and a substantial increase in round complexity [LLR02, BY03, KK06]

13. Our Motivation • If the broadcast channel is emulated by a randomized protocol, then each round of broadcast can be emulated in an expected constant number of rounds (assuming honest majority) [FM88, FG03, KK06] • But the exact constant is rather high • If broadcast is used in more than one round, then we need to handle sequential composition of protocols without simultaneous termination — leads to complication and a substantial increase in round complexity [LLR02, BY03, KK06]

14. Our Motivation Sequential composition of protocols without simultaneous termination • In a broadcast protocol, each party is assumed to start at the same round • However, parties may leave at different rounds • So parties may start execution of the next protocol in different rounds • If protocols are executed sequentially, additional rounds are needed to handle the composition

15. Our Motivation • If the broadcast channel is emulated by a randomized protocol, then each round of broadcast can be emulated in an expected constant number of rounds (assuming honest majority) [FM88, FG03, KK06] • But the exact constant is rather high • If broadcast is used in more than one round, then we need to handle sequential composition of protocols without simultaneous termination — leads to complication and a substantial increase in round complexity [LLR02, BY03, KK06]

16. Our Motivation • If the broadcast channel is emulated by a randomized protocol, then each round of broadcast can be emulated in an expected constant number of rounds (assuming honest majority) [FM88, FG03, KK06] • But the exact constant is rather high • If broadcast is used in more than one round, then we need to handle sequential composition of protocols without simultaneous termination — leads to complication and a substantial increase in round complexity [LLR02, BY03, KK06]

17. Our Motivation For example, • Consider the setting in which at most one-third of parties are corrupted • Micali and Rabin show a Verifiable Secret Sharing (VSS) protocol that uses 16 rounds but only a single round of broadcast • Compiling the above protocol for a point-to-point network, it runs in an expected 31 rounds • Any protocol that uses broadcast twice will require an expected 55 rounds after being compiled for a point-to-point network

18. Our Motivation • If the ultimate goal is a round-efficient protocol for point-to-point networks, then it is preferable to focus on minimizingthe number of rounds in which broadcast is used rather than minimizing the total number of rounds

19. Our Motivation • This raises the following question: Is it possible to construct a constant-round (or sub-linear-round) MPC protocol that uses only a single round of broadcast? (This is clearly optimal…) • We resolve the above question in the affirmative in a number of settings

20. The Rest of the Talk • Prior work • Results and constructions • Future directions

21. Prior Work • Broadcast/Byzantine agreement • Verifiable secrete sharing (VSS) • General secure MPC

22. Prior Work • Broadcast/Byzantine agreement • Reviewed in the last talk • Verifiable secrete sharing (VSS) • General secure MPC

23. Prior Work • Broadcast/Byzantine agreement • Verifiable secrete sharing (VSS) [CGMA85] • General secure MPC

24. Prior Work Round complexity of VSS (Let t be the number of corrupted parties; n be the total number of parties) • [GIKR01]: • n > 4t : Efficient 2-round protocol • n > 3t : No 2-round protocol exists Efficient 4-round protocol Inefficient3-round protocol • [FGGRS06]: Efficient 3-round protocol for n > 3t

25. Prior Work But… • Previous work studies the round complexity of VSS under the assumption that a broadcast channel is available • As we have seen, this is not necessarily the best way to optimize round complexity of VSS in a point-to-point setting

26. Prior Work • Broadcast/Byzantine Agreement • Verifiable Secrete Sharing (VSS) • General Secure MPC

27. Prior Work • Secure MPC • Allows a set of parties with private inputs to compute some joint function of their inputs. • Feasibility results • [BGW88, CDD88]: MPC for n > 3t in point-to point networks • [RB89, B89, CDDHR99]: MPC for n > 2t assuming a broadcast channel

28. Prior Work • Round-efficient solutions • [BMR90, DI05]: constant-round MPC for n> 2t assuming a broadcast channel and one-way functions • Both protocols can be converted to expected O(1)-round protocols in point-to-point networks using authenticated broadcast

29. Prior Work • Round-efficient solutions • [BMR90, DI05]: constant-round MPC for n> 2t assuming a broadcast channel and one-way functions • Both protocols can be converted to expected O(1)-round protocols in point-to-point networks using authenticated broadcast but the constant obtained is very high, on the order of hundreds of rounds

30. Prior Work • Round-efficient solutions • [GIKR01]: 3-round MPC for t < n/4 assuming a broadcast channel and one-way functions • The protocol uses only a single round of broadcast • Resilience is not optimal • [GL02]: round-efficient protocols for t < n • Fairness and output delivery not guaranteed

31. The Rest of the Talk • Prior work • Results and constructions • Future directions

32. Network Assumptions • Synchronous communication • Pairwise private and authenticated channels • A broadcast channel • With the understanding that it will be emulated by a round-efficient broadcast sub-routine • Recall, our goal is to use broadcast only once • Honest majority • n > 3t : do not assume setup • n > 2t : assume a PKI • Adaptive adversary

33. Results and Constructions • We start by sketching a MPC protocol that uses only a single round of broadcast • Call (a, b, c) a random multiplication triple if • c = ab • a, b, and c have been “shared” among the parties • a and b are uniformly distributed

34. Results and Constructions • Beaver shows that if, ina “setup” phase, parties share their inputs along with sufficiently-many multiplication triples,

35. Results and Constructions • Beaver shows that if, ina “setup” phase, parties share their inputs along with sufficiently-many multiplication triples, then the parties can carry out secure MPC in a round-efficient manner without using any further invocations of broadcast • Our task is now reduced to implement the setup phase using only a single round of broadcast

36. Results and Constructions Implementation of the setup phase • Recall the concept of moderated protocol from the previous talk • There is a distinguished party Pm known as the moderator • Given a protocol , designed under the assumption of a broadcast channel, the moderated version ’ does not use broadcast

37. Results and Constructions Implementation of the setup phase • ’ has the following properties: • By the end of the protocol, each party Pi outputs a binary value trusti(m) • If the moderator Pm is honest, then each honest party outputs trusti(m)= 1 • If an honest party that outputs trusti(m)=1, then  achieves the functionality of ’

38. Results and Constructions Implementation of the setup phase • Previous talk has illustrated how to compile a protocol  into its moderated version ’ while increasing the round complexity by at most a constant multiplicative factor

39. Results and Constructions Implementation of the setup phase • Let i denote some constant-round protocol, designed assuming a broadcast channel, that shares the input value of party Pi as well as sufficiently-many multiplication triples. • Such protocols are constructed in, e.g., [BGW88, B89, RB89, B91, GRR98, CDDHR99, DI05] • Compile iinto a moderated protocol i’ where Pi acts as the moderator

40. Results and Constructions • Implementation of the setup phase 1. Run protocols {1’,…,n’ } in parallel 2. Each party Pi broadcasts {trusti(1),…, trusti(n)} 3. A party Pi is disqualified if t or fewer parties broadcast trustj(i)=1. If a party is disqualified, then a default value is used as input of Pi 4. Let i* be the minimum value such that Pi* is not disqualified. The set of random multiplication triples that the parties will use is taken to be the set that was generated in i*

41. Results and Constructions • Implementation of the setup phase 1. Run protocols {1’,…,n’ } in parallel 2. Each party Pi broadcasts {trusti(1),…, trusti(n)} 3. A party Pi is disqualified if t or fewer parties broadcast trustj(i)=1. If a party is disqualified, then a default value is used as input of Pi 4. Let i* be the minimum value such that Pi* is not disqualified. The set of random multiplication triples that the parties will use is taken to be the set that was generated in i* • The above protocol uses broadcast in only one round

42. Results and Constructions • Implementation of the setup phase 1. Run protocols {1’,…,n’ } in parallel 2. Each party Pi broadcasts {trusti(1),…, trusti(n)} 3. A party Pi is disqualified if t or fewer parties broadcast trustj(i)=1. If a party is disqualified, then a default value is used as input of Pi 4. Let i* be the minimum value such that Pi* is not disqualified. The set of random multiplication triples that the parties will use is taken to be the set that was generated in i* • An honest party will not be disqualified

43. Results and Constructions • Implementation of the setup phase 1. Run protocols {1’,…,n’ } in parallel 2. Each party Pi broadcasts {trusti(1),…, trusti(n)} 3. A party Pi is disqualified if t or fewer parties broadcast trustj(i)=1. If a party is disqualified, then a default value is used as input of Pi 4. Let i* be the minimum value such that Pi* is not disqualified. The set of random multiplication triples that the parties will use is taken to be the set that was generated in i* • If Pi is not disqualified, then i’ achieves the functionality of i

44. Results and Constructions • Implementation of the setup phase 1. Run protocols {1’,…,n’ } in parallel 2. Each party Pi broadcasts {trusti(1),…, trusti(n)} 3. A party Pi is disqualified if t or fewer parties broadcast trustj(i)=1. If a party is disqualified, then a default value is used as input of Pi 4. Let i* be the minimum value such that Pi* is not disqualified. The set of random multiplication triples that the parties will use is taken to be the set that was generated in i* • The above protocol implements the setup phase using only one round of broadcast

45. Results and Constructions • Combined with [BGW88, CDDHR99, DI05], we obtain MPC using only one round of broadcast and: • O(depth of the circuit) rounds, assuming n > 3t (without computational assumption) • O(1) rounds, assuming n > 3t and the existence of one-way functions • O(1) rounds, assuming n > 2t, the existence of one-way functions, and a PKI

46. Results and Constructions • However, a naïve compilation will yield MPC protocols with relatively high round complexity • Existing construction of idoes not attempt to minimize the number of rounds of broadcast • for n > 3t, each round of broadcast in i is replaced by six rounds of interaction in i’ • for n > 2t, it is eight rounds • We construct a new set of protocols that minimize their use of broadcast as well as the total number of rounds

47. Results and Constructions • In the following, we illustrate one of the techniques used to reduce the number of rounds of broadcast— without compilation • We show how to obtain a 6-round VSS protocol that uses 2 rounds of broadcast from the 4-round VSS protocol in [GIKR01] (which uses 3 rounds of broadcast) • In the paper, this is improved to 7 rounds with 1 round of broadcast

48. Results and Constructions VSS – informal definitions • There is a dealer D with an input s. A VSS protocol is a 2-phase protocol: • Sharing phase: D shares s • Reconstruction phase: The parties reconstruct a value s’ • If D is honest, then: • During the sharing phase, the joint view of corrupted parties is independent of s • In the reconstruction phase, s is reconstructed

49. Results and Constructions VSS – informal definitions • If D is dishonest: • The view of the honest parties at the end of the sharing phase defines a value s’ that will be reconstructed in the reconstruction phase

50. Results and Constructions • Review of the [GIKR01] protocol: • Round 1: • D selects a random bivariate polynomial F(x,y) of degree t in each variable, s.t. F(0,0) = s; sends F(x,i) = gi(x) and F(i,y) = hi(y) to Pi. • Pi sends to Pj a random pad rij.