Ke Yang
Ph.D. in Computer Science
Carnegie Mellon University
7/17/2016
Ke Yang, CMU
1
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
7/17/2016
Ke Yang, CMU
2
Fair Computation
Ke Yang
Carnegie Mellon University
7/17/2016
Ke Yang, CMU
3
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.
7/17/2016
Ke Yang, CMU
4
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)
7/17/2016
Ke Yang, CMU
5
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/17/2016
Ke Yang, CMU
6
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.
7/17/2016
Ke Yang, CMU
7
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
7/17/2016
Ke Yang, CMU
8
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:




7/17/2016
Proactive without trusted third party
Efficient normal execution
Rigorous and provable security
Applications to the Socialist Millionaires’ Problem
Ke Yang, CMU
9
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.
7/17/2016
Ke Yang, CMU
10
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.
7/17/2016
Ke Yang, CMU
11
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)…
7/17/2016
Ke Yang, CMU
12
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.
7/17/2016
Ke Yang, CMU
13
Example: on-line bidding protocol
seller
(seller.price)
buyer
(buyer.price)
}
(seller.output)
7/17/2016
transcript
(buyer.output)
Ke Yang, CMU
14
Definition of security
seller
(seller.price)
buyer
(buyer.price)
}
(seller.output)
transcript
(buyer.output)
 correctness:
seller.output = buyer.output = f (seller.price, buyer.price)
 privacy: the transcript carries no additional information
about seller.price and buyer.price.
7/17/2016
Ke Yang, CMU
15
“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).
7/17/2016
Ke Yang, CMU
16
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




7/17/2016
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
17
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.
7/17/2016
Ke Yang, CMU
18
Security ≠ fairness
 Security is about absolute information gain.
 A typical security statement --“At the end of the protocol, each party learns at most
y=f(x1,x2,…,xn) and anything inferable from y.”
 Fairness is about relative information gain.
 A typical fairness statement:
“At the end of protocol, either all parties learns
y=f(x1,x2,…,xn), or no party learns anything.”
7/17/2016
Ke Yang, CMU
19
Security  fairness
 Many existing secure MPC/2-PC protocols
are completely unfair.
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.
7/17/2016
Ke Yang, CMU
20
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.
7/17/2016
Ke Yang, CMU
21
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:
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.
7/17/2016
Ke Yang, CMU
22
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!
7/17/2016
Ke Yang, CMU
23
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:




7/17/2016
Proactive without trusted third party
Efficient normal execution
Rigorous and provable security
Applications to the Socialist Millionaires’ Problem
Ke Yang, CMU
24
Designing fair protocols
Q: “If fairness is that important, why
can’t we have fair protocols?”
A: “Because it is impossible!”
7/17/2016
Ke Yang, CMU
25
Impossibility of fair protocols
 [Cleve ’86] There do not exist fair twoparty 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.
7/17/2016
Ke Yang, CMU
26
Wait a minute!
 What’s wrong with Blum’s protocol?
 [Blum ’81] There exists a secure two-party
coin-tossing protocol.
1. Alice generates bit a and sends Commit(a) to Bob.
2. Bob generates bit b and sends b to Alice.
3. Alice opens a to Bob.
4. The result is a XOR b.
Intuition: a XOR b is uniform if either a or b is uniform.
7/17/2016
Ke Yang, CMU
27
Problem: premature abort
1.
2.
3.
4.
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!
7/17/2016
Ke Yang, CMU
28
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!
7/17/2016
Ke Yang, CMU
29
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:




7/17/2016
Proactive without trusted third party
Efficient normal execution
Rigorous and provable security
Applications to the Socialist Millionaires’ Problem
Ke Yang, CMU
30
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.”
7/17/2016
Ke Yang, CMU
31
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




7/17/2016
Ad hoc security notions
Limited general constructions (only 2PC)
Few practical constructions
Weak security (no “Internet Security”)
Ke Yang, CMU
32
Our contributions
 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…
7/17/2016
Ke Yang, CMU
33
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)
7/17/2016
Ke Yang, CMU
34
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).
7/17/2016
Ke Yang, CMU
35
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:
 protocol ,
 adversary A,  simulator S…
new definition:
7/17/2016
Ke Yang, CMU
36
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).
7/17/2016
Ke Yang, CMU
37
Constructing fair protocols
 Now we have a rigorous definition for
security and fairness.
 Next we need to construct protocols
that satisfy this definition.
7/17/2016
Ke Yang, CMU
38
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.
7/17/2016
Ke Yang, CMU
39
FEI is the core of fair 2PC
Once we can solve FEI, we can construct
general fair 2PC protocols easily…
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.
7/17/2016
Ke Yang, CMU
40
Great if we can solve FEI…
So what do we do?
7/17/2016
Ke Yang, CMU
41
Solving FEI using time lines
head
tail
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.
7/17/2016
Ke Yang, CMU
42
A time line, mathematically
accelerator 1
g





g
k-1
2
2
accelerator 2
g
…
…
k-1+2k-2)
(2
2
g
k
2
2
N=p·q, where p, q, (p-1)/2, (q-1)/2 are all primes.
g a random element in ZN*.
2k
2
head = g, tail = g .
one step = one squaring modulo N.
2k
2
Knowing (p,q) makes it easy to compute g .
7/17/2016
Ke Yang, CMU
43
Sounds familiar?
 Time-lines are used before:
 [Boneh-Naor ’00, Garay-Jakobsson ’02, GarayPomerance ’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.
7/17/2016
Ke Yang, CMU
44
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
7/17/2016
Ke Yang, CMU
45
FEI using time-lines
Alice
Bob
t
2t
 ABORT: If Bob aborts and force-open in t steps,
Alice can do it as well in 2t steps.
7/17/2016
Ke Yang, CMU
46
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.”
7/17/2016
Ke Yang, CMU
47
Dealing with cheating parties
Alice
g
2
g2
k-1
g
2
2
g
k-1
A
A
…
(2
g2
k-1+2k-2)
(2
2
g
k-1+2k-2)
A
2
2
g
k
A
Bob
B
B
B
…
k
2
2
gB
 A cheating party might give false accelerators.
 Can add zero-knowledge proofs to enforce
correctness.
 Reasonably efficient protocols.
7/17/2016
Ke Yang, CMU
48
Derived time-lines
k-1
(2
2
g
k-1
(2
2
h
g
2
2
g
h=ga
2
2
h
…
2
2
g
…
2
2
h
k-1+2k-2)
k-1+2k-2)
k
k
 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!
7/17/2016
Ke Yang, CMU
49
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 “gateby-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.
7/17/2016
Ke Yang, CMU
50
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.
7/17/2016
Ke Yang, CMU
51
An application
 We show how to compute the socialist
millionaires’ problem fairly and
efficiently.
7/17/2016
Ke Yang, CMU
52
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 (a>b) 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 (a=b) then 1 else 0}
7/17/2016
Ke Yang, CMU
53
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…
7/17/2016
Ke Yang, CMU
54
We need secure and fair SMP
 Take the authentication problem…
 Security:
 We don’t 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!
7/17/2016
Ke Yang, CMU
55
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 a=b, then y=0; 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 Keyexchange (PAK) and Privacy-Preserving Data Mining
(PPDM).
7/17/2016
Ke Yang, CMU
56
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.
7/17/2016
Ke Yang, CMU
57
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.pdf
7/17/2016
Ke Yang, CMU
58
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]
7/17/2016
Ke Yang, CMU
59
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…
7/17/2016
Ke Yang, CMU
60
Thank you!
7/17/2016
Ke Yang, CMU
61
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” doesn’t work…
 The information might just be one bit.
 Different bits might have different importance.
Alice’s information (for Bob)
real info
7/17/2016
Bob’s information (for Alice)
junk
junk
Ke Yang, CMU
real info
62
A Hierarchical view of game theory
Mechanism Design:
Design a function y=f(x1,x2,…,xn) that satisfy
certain requirement (truthful, etc…)
Multi-Party Computation:
Design a protocol to compute y=f(x1,x2,…,xn)
that maintains privacy, fairness, etc…
7/17/2016
Ke Yang, CMU
63
Intuition behind Cleve’s proof
[Cleve ’86] There do not exist fair twoparty 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.
7/17/2016
Ke Yang, CMU
64
Number theoretical assumptions
 Let N=p·q, where p, q, (p-1)/2, (q-1)/2 are all primes.
 Let g be a random element in ZN*.
T
 Let G = (g, g2, g4, …, g2 ).
 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).
T
 Corollary: g2 takes T steps to compute – if T=2k is large, it
is infeasible to compute.
 YMG-BBS assumption: it appears pseudorandom.
7/17/2016
Ke Yang, CMU
65
Time-line commitments
 Let N=p·q, where p, q, (p-1)/2, (q-1)/2 are all
primes.
 Let g be a random element in ZN*.
T
 Let G = (g, g2, g4, …, g2 ), where T=2k.
 We call G a time line.
 Time-line commitment –
T
(N, g, g2 ·x) 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.
7/17/2016
Ke Yang, CMU
66
More on time-line commitments
 (N, g, g2T·x) is a time-line commitment to x.
 Force-opening takes T=2k steps.
 Gradual opening:
2k-1
2
Step 1: reveal g
– cuts force-opening time by half.
k-1
(2 +2k-2)
2
Step 2: reveal g
– cuts the time by another half.
...
Each step cuts the work by half!
accelerator #1
g
7/17/2016
Step 1
g
k-1
2
2
Ke Yang, CMU
accelerator #2
Step 2
g
…
…
k-1+2k-2)
(2
2
g
k
2
2
67
Intuition: layered blinding
secret (committed value)
g
7/17/2016
2
2
g
k-1
Ke Yang, CMU
(2
2
g
…
k-1+2k-2)
2
2
g
k
68