Fair Multi-Party Computation Framework

1. A Framework for Fair(Multi-Party) ComputationJuan Garay (Bell Labs)Phil MacKenzie (Bell Labs) Ke Yang (CMU)

2. Talk Outline • Multi-party computation (MPC); example; Fair MPC • Fairness definition(s) • Fair protocols with corrupted majority • Fair MPC Framework • Summary & extensions Fair MPC

3. Secure Multi-Party Computation (MPC) Multi-party computation (MPC) [Goldreich-Micali-Wigderson 87] : • n parties {P1, P2, …, Pn}: each Piholds a private input xi • One public function f (x1,x2,…,xn) • All want to learn y = f (x1,x2,…,xn) (Correctness) • Nobody wants to disclose his private input (Privacy) 2-party computation (2PC) [Yao 82, Yao 86]: n=2 Studied for a long time. Focus has been security. Fair MPC

4. Instances of MPC and 2PC • Authentication • Parties: 1 server, 1 client. • Function : if (server.passwd == client.passwd), then return “succeed,” else return “fail.” • On-line Bidding • Parties: 1 seller, 1 buyer. • Function: if (seller.price <= buyer.price), then return (seller.price + buyer.price)/2, else return “no transaction.” • Intuition: In NYSE, the trading price is between the ask (selling) price and bid (buying) price. • Auctions • Parties: 1 auctioneer, (n-1) bidders. • Function: Many possibilities (e.g., Vickrey). Fair MPC

5. Secure Multi-Party Computation Parties P1, P2, …, Pn (some corrupted), each holding private input xi, wish to compute y = f(x1, x2,…, xn) privately and correctly. • Security is normally formulated in a simulation paradigm: • Real world: Parties carry out the protocol. • Adversary Acontrols communication and corrupts parties. • Ideal process: A functionality Ffperforms the computation. • Security: Protocol  securely realizes Ff if • AS s.t. View(, A ) View(Ff, S ) • to any distinguisher (environment) Z. Fair MPC

6. Variants of Security Definitions • Simulation paradigm first in [GMW87], now de facto standard. • Many variants… • Synchronous/asynchronous network • Stand alone/concurrent executions • Single-invocation/reactive • [Goldwasser-Levin 91, Micali-Rogaway 91, Beaver 91, Canetti 00, Pfitzmann-Waidner 00, Pfitzmann-Waidner 01,…] • Universally Composability(UC) framework [Canetti 01]: • Asynchronous network, reactive, allows arbitrary composition • (very strong security) Fair MPC

7. seller buyer (seller.price) (buyer.price) (seller.output) (buyer.output) } transcript On-line Bidding: Definition of Security • Correctness: seller.output = buyer.output = f (seller.price, buyer.price) • Privacy: The transcript carries no additional information about seller.price and buyer.price. Fair MPC

8. “Privacy” is a little tricky… On-line Bidding Function if (seller.price <= buyer.price), then return (seller.price + buyer.price)/2, else return “no transaction.” • If seller.price ≤ buyer.price, then both parties can learn each other’s private input. • If seller.price > buyer.price, then both parties should learn nothing more than this fact. • Privacy: Each party should only learn whatever can be inferred from the output (which can be a lot sometimes). Fair MPC

9. Fair Secure Multi-Party Computation (FMPC) Parties P1, P2, …, Pn (some corrupted), each holding private input xi, wish to compute y = f(x1, x2,…, xn) privately and correctly. Securityis about absolute information gain. “At the end of the protocol, each party learns y (and anything inferable from y).” Fairnessis about relative information gain. “At the end of the protocol, either all parties learn y, or no party learns anything.” Important in MPC; crucial in some appn’s (e.g., two-party contract signing, fair exchange,…). Fair MPC

10. Security vs. Fairness • The problem of secure MPC/2PC is well-studied and well-understood. • Rigorous security notions (simulation paradigm). • General constructions for any (efficient) function. • Practical solutions for specific functions. • Protocols of (very strong) “Internet Security:” concurrency, non-malleability,… • The problem of fair MPC/2PC… • Security and fairness are not only different, but almost • “orthogonal.” Fair MPC

11. Security  Fairness On-line Bidding Function if (seller.price <= buyer.price), then return (seller.price + buyer.price)/2 else return “no transaction.” E.g., in an unfairon-line bidding protocol, the seller may learn the output (and thus buyer.price) before the buyer learns anything. Fair MPC

12. Cheating with Unfair Protocols A cheating seller: • Initiate protocol w/ price x (originally $999,999). • Run until getting the output (buyer hasn’t got the output yet). • if (output == “no transaction”), thenabort (e.g., announce “network failure”), set x  x-1, and repeat. A cheating seller can: • find out the buyer’s price (destroys privacy) and • achieve maximum profit (destroys correctness) (the actual function computed is {return buyer.price}) The lack of fairness completely voids the security! Fair MPC

13. Fairness: Positive Results • n parties, t corrupted: • t  n/3— possible with p2p channels • – computational [GMW87] • – information-theoretic [BGW88, CCD88] • n/3  t  n/2— possible with broadcast channel • – computational [GMW87] • – information-theoretic [RB89] Fair MPC

14. [Cleve 86] No “fair” two-party coin-tossing protocol exists. More formally: For every protocol , there exists an adv. A s.t. A makes  unfair. Unfortunately… • Fairness is impossible with corrupted majority (t  n/2): Intuition (2 parties): Party sending the last message may abort early. • Consequently, many security definitions do not consider fairness, • or only consider partial fairness [BG90, BL91, FGHHS02, GL02]. Fair MPC

15. Fairness After the Impossibility Result We still need (some form of) fairness, so “tweak” model/definition: • “Optimistic” approach (tweak the model) [M97, ASW98, CC00,…] • Adds a trusted party as an arbiter in case of dispute. • Needs to be (constantly) available. • “Gradual Release” approach (tweak the definition) [Blum83, D95, • BN00,…] • No trusted party needed. • Parties take turns releasing info’ “little-by-little.” • Still somewhat unfair, but we can quantify and control the • amount of “unfairness.” Fair MPC

16. The Gradual Release Approach • Reasonably studied • Initial idea by [Blum 83] • Subsequent work: […,Damgard 95, Boneh-Naor 00, Garay-Pomerance 03, Pinkas 03,…] • Not quite well-understood • Ad hoc security notions • Limited general constructions (only 2PC) • Few practical constructions • No “Internet Security” Fair MPC

17. Security definition: • The computation phase is simulatable; • The revealing phase is simulatable if S knows y. • If Acan find y in time t, then honest parties can find y in time • “comparable” to t. Previous Security Definitions • A typical gradual release protocol (e.g., [BN00, GP03, P03]) consists of two phases: • Computation phase: “Normal” computation. • Revealing phase: Each Pigradually reveals a “secret” si ; then each Picomputes the result y from s1, s2,…, sn. Fair MPC

18. Security definition: • The computation phase is simulatable; • The revealing phase is simulatable if S knows y. • If Acan find y in time t, then honest parties can find y in time • “comparable” to t. Previous Security Definitions (cont’d) Definition is not in the simulation paradigm: Suppose Aaborts early and doesn’t have enough time to find y. Then Sshouldn’t know y either… But then the revealing phase is not simulatable! A may gain advantage by simply aborting early. This becomes even worse when protocols are composed… Fair MPC

19. Simulation Paradigm and Fairness • Traditional (security) definition: protocol ,adversaryA,simulatorS s.t. View( , A ) ≈ View(F , S ). • Doesn’t work with fairness! • [Cleve ’86] (for 2PC, or corrupted majority) protocol , adversaryA s.t. A makes  unfair (unsimulatable). Fair MPC

20. Our Security Definition • Our approach: Allows  to depend on the running time of A. Timed protocol[T] = {[t]}, parameterized by the adversary’s running time. Each[t]is a “normal” protocol for eacht. • Security definition (Bounded-Adversary Security): • [T]securely realizes Ff if • t , Aof time t ,  ideal adversaryS s.t. • View([t], A ) View(Ff , S (t) ) • for any distinguisher (environment) Z of running time t . Fair MPC

21. What about Fairness? • Fairness definition (two party case):A timed protocol [T]is • fair if the running time of [t]isO(t). More formally/general:[T]is -fair if each honest party’s running time in [t]is bounded by · t+ p, for a fixed poly. p. [T]is fair if  = O(n). • Intuition: “Whatever and adversary can compute in time t, an • honest party can compute in time comparable to t as well.” • What about abort-free runs? • Reasonable protocols:[T]isreasonable if the “normal” (abort- • free ) running time of [t] is a fixed poly. independent of t. Fair MPC

22. Talk Outline • Multi-party computation (MPC); example; Fair MPC • Fairness definition(s) • Fair protocols with corrupted majority • Fair MPC Framework • Summary & extensions √ √ Fair MPC

23. Unfair! • Honest parties reveal their secrets, and corrupted parties abort (and learn the result). Observation on Existing MPC Protocols Many (unfair) MPC protocols (e.g., [GMW87, CDN01, CLOS02]) share the same structure: Sharing phase: Parties share data among themselves (simple sharing, or (n, t) threshold sharing) Evaluation phase: “Gate-by-gate” evaluation (all intermediate data are shared or “blinded”) Revealing phase: Each party reveal its secret share (all parties learn the result from the shares) Fair MPC

24. FCPFO : Commit-Prove-Fair-Open • Commit phase:Every party Picommits to a value xi. • Prove phase:Every party Pi proves a relation about xi. • Open phase:Open x1, x2,…, xnsimultaneously. Simultaneous opening guarantees fairness — either all parties learn all the committed values, or nobody learns anything. Using FCPFO, the revealing phase becomes fair, and so does the MPC protocol. Fair MPC

25. head tail Time-lines:Towards realizingFCPFO • A time-line: An array of numbers (head, …, tail). • Time-line commitments: • TL-Commit(x) = (head, tail·x) • Perfect binding. • Hiding (2k steps to compute tail from head). • Gradual opening: Each accelerator cuts the number of steps by half. … accelerator 1 accelerator 2 accelerator k Fair MPC

26. A time-line, mathematically [BN00,GJ02,GP03] • N: “safe Blum modulus,” N = p·q, where p, q, (p-1)/2, (q-1)/2 are all primes. • g a random element in ZN*. • head = g, tail = g22k … accelerator 1 accelerator 2 … g g22k-1 g2(2k-1+2k-2) g22k Fair MPC

27. A time-line, mathematically (cont’d) • C • Canmove forward m positions by doing m squarings. … accelerator 1 accelerator 2 … g g22k-1 g2(2k-1+2k-2) g22k • • Knowing (N), one can compute G[i] = g22i efficiently, for any i. • • Conjecture: Hard to move backward, not knowing factorization of N; inefficient to move forward (step-by-step)  point “far away” is “unknown”… • Difference:New “Yet-More-General BBS Assumption” (YMG-BBS). Fair MPC

28. Fair exchange using time-lines • START: Alice has a, Bob has b. • COMMIT: • Alice sends TL-Commit(a) to Bob, • Bob sends TL-Commit(b) to Alice. • OPEN: Take turns to gradually open the commitments. Alice Bob Fair MPC

29. t 2t Fair exchange using time-lines (cont’d) • ABORT: If Bob aborts and force-opens in t steps, Alice can do it as well in 2t steps. Alice Bob Fair MPC

30. Realizing FCPFO using time-lines • Setup:A “master” time-line T = N; g; G[j], j=1,…,kin CRS. • Commit:Each party Pi : • Derives a time-line Ti= N; gi; Gi[j]; • TL-commits to xi : (gi; Gi[k]·xi), • Prove: Standard ZK proof. • Open:In round m, each party Pireveals Gi[m] with ZK proof; • if any party aborts, enter panic mode. • Panic mode: Depends on current round m… • If (k-m) is “large,” then abort. • (A does not have enough time to force-open.) • If (k-m) is “small,” then force-open. • (A has enough time to force-open as well.) Fair MPC

31. Putting things together… Plug FCPFO into existing MPC protocols  Fair MPC protocols • [Canetti-Lindell-Ostrovsky-Sahai 02] • A fair MPC protocol in the CRS model. • [Cramer-Damgard-Nielsen 01] • An efficient fair MPC protocol in the PKI model. • — the CDN protocol is efficient • — added FCPFOcan be realized efficiently • Efficient and fair solution to the Socialist Millionaires’ Problem • (aka PET — remember the authentication problem?) Fair MPC

32. The Fair MPC Framework Fair MPC: Variant of the UC framework to make fairness possible. • Interactive PRAMs: Machines that allow for simulation and • subroutine access with no overhead. • Ideal process: “Direct-output functionalities” — results from ideal • functionality go directly to the parties. • In UC, Smay not forward the results, making the protocol unfair. • Real world/ideal process: Synchronous broadcast with rounds. • Asynchronous communication is inherently unfair (e.g., starvation). Note:FMPC only provides the possibilityof having fair ideal functionalities. Always possible to have unfair functionalities/ protocols. Fair MPC

33. A Composition Theorem in the FMPC Framework Similar to composition theorem in UC… • More complicated since we deal with timed protocols. • We need to consider the precise running time of adversaries • (bounded-adversary composition). • Intuitively: Any secure protocol in FMPC remains secure when • arbitrarily composed. In particular, concurrently secure and • non-malleable. Fair MPC

34. Summary & Extensions • Fair MPC framework + rigorous definition of security/fairness. • First in the simulation paradigm. • Construction of secureand fair protocols. • A general technique to convert completely unfair MPC/2PC protocols into fair ones. • First fair MPC protocols with corrupted majority. • Efficient, practical for specific applications. • The Socialist Millionaires’ Problem. • “Internet Security” • Concurrency, non-malleability… Fair MPC

35. Summary & Extensions (cont’d) • [t] ?! Why should A have a fixed time bound in advance? On-going: Determine time dynamically — more complicated ideal process. • References: • J. Garay, P. MacKenzie and K. Yang, “Efficient and Secure • Multi-Party Computation with Faulty Majority and Complete • Fairness.” Available from Cryptology ePrint archive (Jan. 2004). Fair MPC

36. “Time is on my side —yes it is”Juan GarayBell Labs – Lucent Technologies