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

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

3. 06/09/04Fair MPC3 Secure Multi-Party Computation (MPC) Multi-party computation (MPC) [Goldreich-Micali-Wigderson 87] : –n parties {P 1, P 2, …, P n }: each P i holds a private input x i –One public function f (x 1,x 2,…,x n ) –All want to learn y = f (x 1,x 2,…,x n ) ( 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.

4. 06/09/04Fair MPC4 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).

5. 06/09/04Fair MPC5 Secure Multi-Party Computation Security is normally formulated in a simulation paradigm : Real world : Parties carry out the protocol. Adversary A controls communication and corrupts parties. Ideal process : A functionality F f performs the computation. Parties P 1, P 2, …, P n (some corrupted), each holding private input x i, wish to compute y = f(x 1, x 2,…, x n ) privately and correctly. Security: Protocol  securely realizes F f if  A  S s.t. View ( , A )  View ( F f, S ) to any distinguisher (environment) Z.

6. 06/09/04Fair MPC6 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)

7. 06/09/04Fair MPC7 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. seller buyer (seller.price) (buyer.price) (seller.output) (buyer.output) } transcript

8. 06/09/04Fair MPC8 “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).

9. 06/09/04Fair MPC9 Fair Secure Multi-Party Computation (FMPC) Security is about absolute information gain. “ At the end of the protocol, each party learns y (and anything inferable from y). ” Parties P 1, P 2, …, P n (some corrupted), each holding private input x i, wish to compute y = f(x 1, x 2,…, x n ) privately and correctly. Fairness is 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,…).

10. 06/09/04Fair MPC10 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.”

11. 06/09/04Fair MPC11 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 unfair on-line bidding protocol, the seller may learn the output (and thus buyer.price) before the buyer learns anything.

12. 06/09/04Fair MPC12 Cheating with Unfair Protocols A cheating seller: 1.Initiate protocol w/ price x (originally $999,999). 2.Run until getting the output (buyer hasn ’ t got the output yet). 3.if (output == “ no transaction ” ), then abort (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!

13. 06/09/04Fair MPC13 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]

14. 06/09/04Fair MPC14 Unfortunately… Fairness is impossible with corrupted majority (t  n/2): More formally: For every protocol , there exists an adv. A s.t. A makes  unfair. [Cleve 86] No “fair” two-party coin-tossing protocol exists. 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].

15. 06/09/04Fair MPC15 Fairness After the Impossibility Result We still need (some form of) fairness, so “tweak” model/definition: “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.” “Optimistic” approach (tweak the model) [M97, ASW98, CC00,…] Adds a trusted party as an arbiter in case of dispute. Needs to be (constantly) available.

16. 06/09/04Fair MPC16 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”

17. 06/09/04Fair MPC17 Previous Security Definitions A typical gradual release protocol (e.g., [BN00, GP03, P03]) consists of two phases: 1.Computation phase: “Normal” computation. 2.Revealing phase: Each P i gradually reveals a “secret” s i ; then each P i computes the result y from s 1, s 2,…, s n. Security definition: 1.The computation phase is simulatable; 2.The revealing phase is simulatable if S knows y. 3.If A can find y in time t, then honest parties can find y in time “comparable” to t.

18. 06/09/04Fair MPC18 Previous Security Definitions (cont’d) Definition is not in the simulation paradigm: Suppose A aborts early and doesn’t have enough time to find y. Then S shouldn’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… Security definition: 1.The computation phase is simulatable; 2.The revealing phase is simulatable if S knows y. 3.If A can find y in time t, then honest parties can find y in time “comparable” to t.

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

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

21. 06/09/04Fair MPC21 What about Fairness? Fairness definition (two party case) : A timed protocol [T] is fair if the running time of [t] is O(t). 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] is reasonable if the “normal” (abort- free ) running time of [t] is a fixed poly. independent of 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).

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

23. 06/09/04Fair MPC23 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) Unfair! Honest parties reveal their secrets, and corrupted parties abort (and learn the result).

24. 06/09/04Fair MPC24 F CPFO : Commit-Prove-Fair-Open Commit phase: Every party P i commits to a value x i. Prove phase: Every party P i proves a relation about x i. Open phase: Open x 1, x 2,…, x n simultaneously. Using F CPFO, the revealing phase becomes fair, and so does the MPC protocol. Simultaneous opening guarantees fairness — either all parties learn all the committed values, or nobody learns anything.

25. 06/09/04Fair MPC25 Time-lines : Towards realizing F CPFO A time-line: An array of numbers (head, …, tail). Time-line commitments: –TL-Commit(x) = (head, tail · x) –Perfect binding. –Hiding (2 k steps to compute tail from head). –Gradual opening: Each accelerator cuts the number of steps by half. … headtail accelerator 1 accelerator 2 accelerator k

26. 06/09/04Fair MPC26 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 Z N *. head = g, tail = g 2 2 k g22kg22k g g 2 2 k-1 g 2 (2 k-1+ 2 k-2 ) … accelerator 1accelerator 2 …

27. 06/09/04Fair MPC27 A time-line, mathematically (cont’d) g22kg22k g g 2 2 k-1 g 2 (2 k-1+ 2 k-2 ) … accelerator 1accelerator 2 … C Can move forward m positions by doing m squarings. Knowing  (N), one can compute G[i] = g 2 2 i 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).

28. 06/09/04Fair MPC28 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. Bob Alice

29. 06/09/04Fair MPC29 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. Bob Alice t 2t

30. 06/09/04Fair MPC30 Realizing F CPFO using time-lines Setup: A “ master ” time-line T =  N; g; G[j], j=1,…,k  in CRS. Commit: Each party P i : Derives a time-line T i =  N; g i ; G i [j]  ; TL-commits to x i : (g i ; G i [k] · x i ), Prove: Standard ZK proof. Open: In round m, each party P i reveals G i [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.)

31. 06/09/04Fair MPC31 Putting things together… [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 F CPFO can be realized efficiently Efficient and fair solution to the Socialist Millionaires’ Problem (aka PET — remember the authentication problem?) Plug F CPFO into existing MPC protocols  Fair MPC protocols

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

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

34. 06/09/04Fair MPC34 Summary & Extensions Fair MPC framework + rigorous definition of security/fairness. –First in the simulation paradigm. Construction of secure and 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…

35. 06/09/04Fair MPC35 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).

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