Ke Yang

1

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

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

3

• Fair Computation
• Ke Yang
• Carnegie Mellon University

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.

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

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.

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

9
This talk is about fairness
v

• Fair exchange a fundamental problem in security
  as well as in business
• Fairness beyond fair exchange
• Why we didnt have fair solutions
• Our solution
• Proactive without trusted third party
• Efficient normal execution
• Rigorous and provable security
• Applications to the Socialist Millionaires
  Problem

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.

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 yf(x1,x2,,xn)
• None wants to disclose his private input
• 2-party computation (2PC) n2

We work with 2PC for most of the talk.
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 lt 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)

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.

14
Example on-line bidding protocol
15
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.

16
Privacy is a little tricky

• On-line Bidding Function
• if (seller.price lt buyer.price),
• then return (seller.price buyer.price)/2,
• else return no transaction.
• If seller.price buyer.price, then both parties
  can learn each others private input.
• If seller.price gt 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).

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

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.

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 yf(x1,x2,,xn) and anything inferable from
y.
At the end of protocol, either all parties
learns yf(x1,x2,,xn), or no party learns
anything.
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 lt
buyer.price), then return (seller.price
buyer.price)/2 else return no transaction.
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.

22
How to cheat w/ an unfair protocol

• On-line Bidding Function
• if (seller.price lt 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 hasnt got
  the output yet).
• if (output no transaction), then abort (e.g.
  announce network failure), set x ? x-1, and
  repeat.

23
Cheating with unfair protocols

• A cheating seller
• Initiate protocol w/ price x (originally
  999,999).
• Run until getting the output (buyer hasnt got
  the output yet).
• if (output no transaction), then abort (e.g.
  announce network failure), set x ? x-1, and
  repeat.

• A cheating seller can
• find out the buyers 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!

24
Fair exchange and beyond
v

• Fair exchange a fundamental problem in security
  as well as in business
• Fairness beyond fair exchange
• Why we didnt have fair solutions
• Our solution
• Proactive without trusted third party
• Efficient normal execution
• Rigorous and provable security
• Applications to the Socialist Millionaires
  Problem

v
25
Designing fair protocols

• Q If fairness is that important, why cant we
  have fair protocols?
• A Because it is impossible!

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.

27
Wait a minute!

• Whats wrong with Blums 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.

28
Problem premature abort

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

• 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!

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 lt n/3 yes with point-to-point network.
• n/3 t lt n/2 yes with broadcast network.
• n/2 t (fault majority) no!

30
What to do next?
v

• Fair exchange a fundamental problem in security
  as well as in business
• Fairness beyond fair exchange
• Why we didnt have fair solutions
• Our solution
• Proactive without trusted third party
• Efficient normal execution
• Rigorous and provable security
• Applications to the Socialist Millionaires
  Problem

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

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)

33
Our contributions
v

• A 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 protocol with corrupted majority.
• Efficient, practical for specific applications.
• E.g. the Socialist Millionaires Problem
• Very strong Internet Security
• Concurrency, non-malleability

v
v
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)

35
Simulation paradigm and fairness

• Tradition (security) definition
• ? protocol ?, ? adversary A, ? simulator S, s.t.
• View(A, ?) View(S, F).
• Doesnt work with fairness!
• Cleve 86 (for 2PC)
• ? protocol ?, ? adversary A, s.t.
• A makes ? unfair (unsimulatable).

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 ?,
? adversary A,
? simulator S
? protocol ?,
? adversary A,
? simulator S
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 first rigorous security/fairness definition
  that completely falls in the simulation paradigm
  (previous ones are rather ad hoc).

38
Constructing fair protocols

• Now we have a rigorous definition for security
  and fairness.
• Next we need to construct protocols that satisfy
  this definition.

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.

40
FEI is the core of fair 2PC

• Once we can solve FEI, we can construct general
  fair 2PC protocols easily

41
Great if we can solve FEI

• So what do we do?

42
Solving FEI using time lines

accelerator 1
accelerator 2
accelerator k

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

43
A time line, mathematically

accelerator 1
accelerator 2

g
g22k
g22k-1
g2(2k-12k-2)

• Npq, 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 .

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.

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
46
FEI using time-lines
Alice
Bob

• ABORT If Bob aborts and force-open in t steps,
  Alice can do it as well in 2t steps.

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.

48
Dealing with cheating parties
Alice

g
g22k-1
g2(2k-12k-2)
g22k
A
A
A
A
Bob

g
g22k-1
g2(2k-12k-2)
g22k
B
B
B
B

• A cheating party might give false accelerators.
• Can add zero-knowledge proofs to enforce
  correctness.
• Reasonably efficient protocols.

49
Derived time-lines

g
g22k
g22k-1
g2(2k-12k-2)

hga
h22k
h22k-1
h2(2k-12k-2)

• 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!

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.

51
Fair MPC/2PC

• THEOREM There exist secure and fair 2PC
  protocols for any (efficiently) function.
• MPC can extend FEI to multi-party case
• P1, P2, , Pn each Pi holds a private input xi
• Either all parties learn everything, or no one
  learns anything.
• Similar solution using time-lines.

52
An application

• We show how to compute the socialist
  millionaires problem fairly and efficiently.

53
The Socialist Millionaires Problem

• The Millionaires Problem
• Alice has a million, Bob has b million.
• They want to compare who is richer but not
  disclosing a or b.
• f(a,b) if (agtb) then 1 else 0
• The Socialist Millionaires Problem (SMP)
• Alice has a million, Bob has b million.
• They want to compare if they are equal but not
  disclosing a or b.
• f(a,b) if (ab) then 1 else 0

54
SMP is useful!

• Remember the authentication problem?
• Parties 1 server, 1 client
• Function if (server.passwd client.passwd),
  then return succeed, else return fail.
• This is exactly SMP!
• SMP is also known as private equality testing a
  basic building block for Privacy-Preserving Data
  Mining (PPDM).
• Many applications in cryptography, security, and
  e-commerce

55
We need secure and fair SMP

• Take the authentication problem
• Security
• We dont want a cheating client/server to learn
  the password by trying a bad one
• Fairness
• Typically the server limits the number of
  unsuccessful attempts to prevent on-line attacks.
• Unfair for clients with bad connection.
• Need a fair protocol!

56
Our solution for fair SMP

• Based on ideas from Cramer-Damgard-Nielsen 01,
  Damgard-Nielsen 03
• Alice has a, Bob has b.
• They jointly compute y(a-b)r for a random r.
• If ab, then y0 otherwise y is a random
  non-zero number.
• Efficient protocol to compute y(a-b)r.
• We make it fair and strongly secure (Internet
  security).
• Direct applications in Password Authenticated
  Key-exchange (PAK) and Privacy-Preserving Data
  Mining (PPDM).

57
Conclusions

• Fairness is about relative information gain,
  almost orthogonal to security, which is about
  absolute information gain.
• Important to design fair protocols fundamental
  by itself the lack of fairness may destroy the
  security.
• Impossibility result premature abort.
• Gradual release approach to control the
  unfairness.
• Time-line solution for FEI unfairness is 2x in
  time.
• First MPC protocol that is fair and secure with
  faulty majority.

58
References

• Juan Garay, Philip MacKenzie and Ke Yang
• Efficient and Secure Multi-Party Computation
  with Faulty Majority and Complete Fairness
• Paper available on-line at http//www.cs.cmu.edu/
  yangke/papers/fmpc.ps
• A more technical version of this talk at
• http//www.cs.cmu.edu/yangke/papers/fmpc-talk.pd
  f

59
My other work in cryptography

• Non-malleability
• Zero Knowledge Garay-MacKenzie-Y 03
• Encryption MacKenzie-Reiter-Y 04
• Oblivious Transfer Garay-MacKenzie-Y 04
• Commitment MacKenzie-Y 04
• Obfuscation and tamper-resistance (security and
  non-malleability of programs)
• Impossibility of obfuscation BGIRSVY 01
• Tamper-resistant software library (with Eric
  Grosse)
• Efficient PIR with applications in anonymous
  communication KORSY 04

60
My other work

• Quantum information theory and quantum
  computation
• Limits in NMR computation Blum-Y 03
• NMR computing uses a different model from the
  standard quantum computing.
• Needs an (inefficient) compiler to covert
  algorithms in standard model to NMR model.
• Our result such inefficiency is inherent.
• EPR pair distillation
• Ambainis-Smith-Y 02, Ambainis-Y 04
• Machine learning and computatoinal complexity

61
Thank you!
62
How do we do FEI?

• Intuitively, release information bit by bit
• So that if Alice aborts prematurely, she is only
  one bit ahead of Bob.
• However, bit by bit doesnt work
• The information might just be one bit.
• Different bits might have different importance.

63
A Hierarchical view of game theory
Mechanism Design Design a function
yf(x1,x2,,xn) that satisfy certain requirement
(truthful, etc)
Multi-Party Computation Design a protocol to
compute yf(x1,x2,,xn) that maintains privacy,
fairness, etc
64
Intuition behind Cleves proof
Cleve 86 There do not exist fair two-party
coin-tossing protocols.

• It is impossible to prevent abort.
• A protocol contains some critical rounds where
  information is exchanged.
• Aborting at a critical round creates unfairness.
• Therefore, at least one party can cause a
  significant bias by aborting.

65
Number theoretical assumptions

• Let Npq, where p, q, (p-1)/2, (q-1)/2 are all
  primes.
• Let g be a random element in ZN.
• Let G (g, g2, g4, , g2T).
• Suppose we want to compute points in G
• sequential access can move one step forward by
  squaring.
• random access can compute any point if we know
  (p,q).
• Assumption without knowing (p,q), can only do
  sequential access (one step at a time).
• Corollary g2T takes T steps to compute if T2k
  is large, it is infeasible to compute.
• YMG-BBS assumption it appears pseudorandom.

66
Time-line commitments

• Let Npq, where p, q, (p-1)/2, (q-1)/2 are all
  primes.
• Let g be a random element in ZN.
• Let G (g, g2, g4, , g2T), where T2k.
• We call G a time line.
• Time-line commitment
• (N, g, g2Tx) is a time-line commitment to
  x
• Efficiently computable knowing (p,q).
• Uniquely determines x (perfect binding).
• Computationally hiding (based on the YMG-BBS
  assumption)
• Force-open in T steps.

67
More on time-line commitments

• (N, g, g2Tx) is a time-line commitment to x.
• Force-opening takes T2k steps.
• Gradual opening
• Step 1 reveal g22k-1 cuts force-opening time
  by half.
• Step 2 reveal g2(2k-12k-2) cuts the time by
  another half.
• ...
• Each step cuts the work by half!

accelerator 2
accelerator 1
68
Intuition layered blinding

g
g22k
g22k-1
g2(2k-12k-2)