Ke Yang Ph.D. in Computer Science Carnegie Mellon University

1. Ke Yang Ph.D. in Computer Science Carnegie Mellon University Ke Yang, CMU

2. My Research Interests… • Cryptography and Security • Fair Computation • Non-malleability • Obfuscation and tamper-resistant software • Quantum information theory and quantum computation • Limitations in NMR computation • EPR pair distillation • Machine Learning • Computational Complexity Theory Ke Yang, CMU

3. Fair Computation Ke Yang Carnegie Mellon University Ke Yang, CMU

4. Fairness: an example • Consider the eBay problem… • Alice sells iPods and Bob wants to buy one. • Alice likes to deliver the iPod only if Bob pays. • Bob likes to pay only if Alice delivers. • We need a fair exchange! either Alice gets the $$$ and Bob gets the iPod, or none gets any. Ke Yang, CMU

5. Fairness means… All should get the “stuff” they want at the same time. (for the rest of this talk, “stuff” = “information”) (fair exchange is a special case) Ke Yang, CMU

6. Fair exchange in business • A fundamental issue • “I should receive what I paid for.” • “I should get paid for what I deliver.” • (Traditional) solutions • Proactive: enforcing fairness in the first place escrow accounts, Cash-On-Delivery... • Reactive: punishing unfair behavior afterwards credit system, legal measures... Ke Yang, CMU

7. proactive vs. reactive • The proactive solution… • is more effective “An ounce of prevention is worth a pound of cure.” • but is typically inefficient Needs a trusted party, complicated procedure… • The reactive solution… • is more efficient and more popular Efficient normal execution (when nothing goes wrong). • but not as effective Not all misbehaviors are caught. Ke Yang, CMU

8. Fairness in e-business • Fair exchange of information: still a fundamental issue. • Complicated by the “e-” • Problems with the proactive solution: efficiency • Need efficient normal execution • Trusted third party can be unrealistic • Problems with the reactive solution: identity • Easy to fake, expensive to verify • Paperless transactions – hard to obtain evidence Ke Yang, CMU

9. This talk is about fairness √ • Fair exchange: a fundamental problem in security as well as in business • Fairness beyond fair exchange • Why we didn’t have fair solutions • Our solution: • Proactive without trusted third party • Efficient normal execution • Rigorous and provable security • Applications to the Socialist Millionaires’ Problem Ke Yang, CMU

10. Fairness beyond exchange • For more complicated tasks, the parties may do more than just exchanging information. • Fairness formulated in the framework of 2-Party Computation (2PC) and Multi-party Computation (MPC) protocols. Ke Yang, CMU

11. MPC and 2PC… Multi-party computation (MPC): • n parties {P1, P2, …, Pn}: each Pi holds a private input xi • One public function f(x1,x2,…,xn) • All want to learn y=f(x1,x2,…,xn) • None wants to disclose his private input 2-party computation (2PC): n=2 We work with 2PC for most of the talk. Ke Yang, CMU

12. 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.” • Rough intuition: in NYSE, the trading price is between the ask (selling) price and bid (buying) price. • Auction • Parties: 1 auctioneer, (n-1) bidders • Function: many possibilities (e.g. Vickrey)… Ke Yang, CMU

13. Secure MPC/2PC • MPC/2PC protocols have been studied for a long time… • The focus was security • Correctness: the protocol computes the right function. • Privacy: the protocol discloses minimal amount of information. Ke Yang, CMU

14. seller buyer (seller.price) (buyer.price) (seller.output) (buyer.output) } transcript Example: on-line bidding protocol Ke Yang, CMU

15. seller buyer (seller.price) (buyer.price) (seller.output) (buyer.output) } transcript 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. Ke Yang, CMU

16. “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). Ke Yang, CMU

17. State of art on secure MPC/2PC • Well-studied • [Yao ’82, Yao ’86] 2PC • [Goldreich-Micali-Wigderson ’87] MPC • many papers to follow… • 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… Ke Yang, CMU

18. Security vs. fairness? • The problem of secure MPC/2PC is well-studied and well-understood. • The problem of fair MPC/2PC is not! • Security and fairness are not only different, but almost orthogonal. Ke Yang, CMU

19. Security ≠ fairness • Security is about absolute information gain. • A typical security statement --- • Fairness is about relative information gain. • A typical fairness statement: “At the end of the protocol, each party learns at most y=f(x1,x2,…,xn) and anything inferable from y.” “At the end of protocol, either all parties learns y=f(x1,x2,…,xn), or no party learns anything.” Ke Yang, CMU

20. Security  fairness • Many existing secure MPC/2-PC protocols are completely unfair. • E.g. in an unfair on-line bidding protocol, the seller may learn the output (and thus buyer.price) before the buyer learns anything. On-line Bidding Function if (seller.price <= buyer.price), then return (seller.price + buyer.price)/2 else return “no transaction.” Ke Yang, CMU

21. Unfair protocols can be bad! • Fair exchange is a fundamental problem itself. • Even when fairness does not seem relevant, an unfair protocol can completely destroy the security… • Example: the on-line bidding problem. Ke Yang, CMU

22. How to cheat w/ an unfair protocol On-line Bidding Function: if (seller.price <= buyer.price), then return (seller.price + buyer.price)/2 else return “no transaction.” 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. Ke Yang, CMU

23. 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! Ke Yang, CMU

24. Fair exchange and beyond √ • Fair exchange: a fundamental problem in security as well as in business • Fairness beyond fair exchange • Why we didn’t have fair solutions • Our solution: • Proactive without trusted third party • Efficient normal execution • Rigorous and provable security • Applications to the Socialist Millionaires’ Problem √ Ke Yang, CMU

25. Designing fair protocols Q: “If fairness is that important, why can’t we have fair protocols?” A: “Because it is impossible!” Ke Yang, CMU

26. Impossibility of fair protocols • [Cleve ’86] There do not exist fair two-party coin-tossing protocols. • coin-tossing protocol: Alice and Bob jointly generate a uniformly distributed bit b. • Fairness: no one should be able to bias b. (different fairness condition: probabilistic function) • The coin-tossing protocol is one of the basic building blocks of MPC/2PC protocols, and its impossibility implies that fair MPC/2PC is in general impossible. Ke Yang, CMU

27. Wait a minute! • What’s wrong with Blum’s protocol? • [Blum ’81] There exists a secure two-party coin-tossing protocol. • Alice generates bit a and sends Commit(a) to Bob. • Bob generates bit b and sends b to Alice. • Alice opens a to Bob. • The result is a XOR b. Intuition: a XOR b is uniform if either a or b is uniform. Ke Yang, CMU

28. Problem: premature abort • Suppose Alice wishes to bias the output towards 0. • (Malicious Alice) in step 3, if a XOR b == 0, then open a; otherwise, abort. • Then the output is always 0! • Alice generates bit a and sends Commit(a) to Bob. • Bob generates bit b and sends b to Alice. • Alice opens a to Bob. • The result is a XOR b. Ke Yang, CMU

29. Summary of the impossibility result • No fair two-party protocols in general. • Case for MPC is more complicated: suppose n parties, t corrupted. • t < n/3: yes with point-to-point network. • n/3 ≤ t < n/2: yes with broadcast network. • n/2 ≤ t(fault majority): no! Ke Yang, CMU

30. What to do next? √ • Fair exchange: a fundamental problem in security as well as in business • Fairness beyond fair exchange • Why we didn’t have fair solutions • Our solution: • Proactive without trusted third party • Efficient normal execution • Rigorous and provable security • Applications to the Socialist Millionaires’ Problem √ √ Ke Yang, CMU

31. Fair protocols? • We still need (some form of) fairness. • We have to “tweak” the model to circumvent the impossibility result. • Tweak the set-up (optimistic approach): Add a trusted party as arbiter in case of abort. • Can achieve full fairness. • Need for trusted party can be unrealistic. • Tweak the definition (gradual release approach): Parties take turns to reveal information “bit by bit.” • No trusted parties needed. • Still somewhat unfair, but we can quantify and control the amount of “unfairness.” Ke Yang, CMU

32. The gradual release approach • Reasonably studied • Initial idea by [Blum ’83] • Subsequent work: [Damgard ’95, Boneh-Naor ’00, Garay-Jakobsson ’02, Pinkas ’03]… • Not quite well-understood • Ad hoc security notions • Limited general constructions (only 2PC) • Few practical constructions • Weak security (no “Internet Security”) Ke Yang, CMU

33. Our contributions √ • A 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 protocol with corrupted majority. • Efficient, practical for specific applications. • E.g. the Socialist Millionaires’ Problem • Very strong “Internet Security” • Concurrency, non-malleability… √ √ Ke Yang, CMU

34. The simulation paradigm • De facto standard in secure MPC/2PC. • A real world: parties engage in protocol . • An ideal world: an ideal functionality F does all the computation (guaranteed correctness, privacy, and fairness). • Simulation: Protocol  securely realizes F, if adversary A,simulator S, s.t. View(A, ) ≈ View(S, F) Ke Yang, CMU

35. Simulation paradigm and fairness • Tradition (security) definition: protocol ,adversary A,simulator S, s.t. View(A, ) ≈ View(S, F). • Doesn’t work with fairness! • [Cleve ’86] (for 2PC) protocol , adversary A, s.t. A makes  unfair (unsimulatable). Ke Yang, CMU

36. Our solution: quantifier switch • A timed protocol[T] is a collection of protocols, parameterized by T: each [t] is a “normal” protocol each t. • A timed protocol [T]securely realizes F, if  t, adversary A of time t,simulator S, s.t. View(A, [t]) ≈ View(S, F) • Notice the quantifier switch: old definition: new definition: protocol , protocol , adversary A, adversary A, simulator S… simulator S… Ke Yang, CMU

37. What about fairness? • In our framework, fairness is simply a statement about the running time of the protocols. • A timed protocol [T]is fair, if the running time of [t] is O(t). • Intuition: “Whatever an adversary can compute in time t, an honest party can compute in time comparable to t as well.” • The firstrigorous security/fairness definition that completely falls in the simulation paradigm (previous ones are rather ad hoc). Ke Yang, CMU

38. Constructing fair protocols • Now we have a rigorous definition for security and fairness. • Next we need to construct protocols that satisfy this definition. Ke Yang, CMU

39. Fair Exchange of Information (FEI) • Alice has a, and Bob has b. • At the end of the protocol, either: • Alice learns b, and Bob learns a, or • No one learns anything. Ke Yang, CMU

40. fair coin-tossing • Alice generates bit a • Bob generates bit b. • Alice and Bob fairly exchange a and b. • The result is a XOR b. FEI is the core of fair 2PC Once we can solve FEI, we can construct general fair 2PC protocols easily… Ke Yang, CMU

41. Great if we can solve FEI… So what do we do? Ke Yang, CMU

42. head tail Solving FEI using time lines • 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 Ke Yang, CMU

43. A time line, mathematically … • 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. • one step = one squaring modulo N. • Knowing (p,q) makes it easy to compute g22k. accelerator 1 accelerator 2 … g g22k-1 g2(2k-1+2k-2) g22k Ke Yang, CMU

44. Sounds familiar? • Time-lines are used before: • [Boneh-Naor ’00, Garay-Jakobsson ’02, Garay-Pomerance ’03] • Our construction is a (simplified) variant of the [Garay-Pomerance ’03]. • Difference: a new Yet-More-General BBS (YMG-BBS) assumption – also needed by previous constructions to work. Ke Yang, CMU

45. FEI 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 Ke Yang, CMU

46. t 2t FEI using time-lines Alice • ABORT: If Bob aborts and force-open in t steps, Alice can do it as well in 2t steps. Bob Ke Yang, CMU

47. Time-lines makes FEI • THM: At any time, if a party aborts and force-opens in time t, the other party can force-open in time 2t. • Intuition: “Whatever an adversary can compute in time t, an honest party can compute in time comparable to t as well.” Ke Yang, CMU

48. Dealing with cheating parties Alice • A cheating party might give false accelerators. • Can add zero-knowledge proofs to enforce correctness. • Reasonably efficient protocols. … g g22k-1 g2(2k-1+2k-2) g22k A A A A Bob … g g22k-1 g2(2k-1+2k-2) g22k B B B B Ke Yang, CMU

49. Derived time-lines • Can derive a new time-line from a master time-line by raising everything to a random power a. • A master time-line in the public parameter (common reference string); each party derives a new time-line and proves correctness. • Very efficient zero-knowledge proofs! … g g22k-1 g2(2k-1+2k-2) g22k … h=ga h22k-1 h2(2k-1+2k-2) h22k Ke Yang, CMU

50. From FEI to Fair 2PC • Most existing (unfair) secure 2PC protocols contains three phases… • Share: parties share their private inputs. • Evaluate: jointly evaluate the function in a “gate-by-gate” fashion. • Reveal: parties reveal their secrets. • The reveal phase makes the protocol unfair. • FEI can make the reveal phase fair, and thus making the entire protocol fair. Ke Yang, CMU