A Framework for Fair
(Multi-Party) Computation
Juan Garay (Bell Labs)
Phil MacKenzie (Bell Labs)
Ke Yang (CMU)
Talk Outline
•
•
•
•
•
Multi-party computation (MPC); example; Fair MPC
Fairness definition(s)
Fair protocols with corrupted majority
Fair MPC Framework
Summary & extensions
06/09/04
Fair MPC
2
Secure Multi-Party Computation (MPC)
Multi-party computation (MPC) [Goldreich-Micali-Wigderson 87] :
–
–
–
–
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)
(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.
06/09/04
Fair MPC
3
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).
06/09/04
Fair MPC
4
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 A controls communication and corrupts parties.
• Ideal process: A functionality Ff performs the computation.
• Security: Protocol  securely realizes Ff if
A  S s.t. View(, A )  View(Ff , S )
to any distinguisher (environment) Z.
06/09/04
Fair MPC
5
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)
06/09/04
Fair MPC
6
On-line Bidding: Definition of Security
seller
buyer
(seller.price)
(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.
06/09/04
Fair MPC
7
“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).
06/09/04
Fair MPC
8
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.
Security is about absolute information gain.
“At the end of the protocol, each party learns y (and anything
inferable from y).”
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,…).
06/09/04
Fair MPC
9
Security vs. Fairness
• The problem of secure MPC/2PC is well-studied and wellunderstood.
–
–
–
–
Rigorous security notions (simulation paradigm).
General constructions for any (efficient) function.
Practical solutions for specific functions.
Protocols of (very strong) “Internet Security:” concurrency, nonmalleability,…
• The problem of fair MPC/2PC…
• Security and fairness are not only different, but almost
“orthogonal.”
06/09/04
Fair MPC
10
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.
06/09/04
Fair MPC
11
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!
06/09/04
Fair MPC
12
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]
06/09/04
Fair MPC
13
Unfortunately…
•
Fairness is impossible with corrupted majority (t  n/2):
Intuition (2 parties): Party sending the last message may
abort early.
•
[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.
• Consequently, many security definitions do not consider fairness,
or only consider partial fairness [BG90, BL91, FGHHS02, GL02].
06/09/04
Fair MPC
14
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.”
06/09/04
Fair MPC
15
The Gradual Release Approach
•
Reasonably studied
– Initial idea by [Blum 83]
– Subsequent work: […,Damgard 95, Boneh-Naor 00, GarayPomerance 03, Pinkas 03,…]
• Not quite well-understood
–
–
–
–
06/09/04
Ad hoc security notions
Limited general constructions (only 2PC)
Few practical constructions
No “Internet Security”
Fair MPC
16
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 Pi gradually reveals a “secret” si ;
then each Pi computes the result y from s1, s2,…, sn.
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.
06/09/04
Fair MPC
17
Previous Security Definitions (cont’d)
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.
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…
06/09/04
Fair MPC
18
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).
06/09/04
Fair MPC
19
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 each t.
• Security definition (Bounded-Adversary Security):
[T] securely realizes Ff if
 t , A of time t ,  ideal adversary S s.t.
View([t], A )  View(Ff , S (t) )
for any distinguisher (environment) Z of running time t .
06/09/04
Fair MPC
20
What about Fairness?
• Fairness definition (two party case): A timed protocol [T] is
fair if the running time of [t] is O(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] is reasonable if the “normal” (abortfree ) running time of [t] is a fixed poly. independent of t.
06/09/04
Fair MPC
21
Talk Outline
å Multi-party computation (MPC); example; Fair MPC
å Fairness definition(s)
• Fair protocols with corrupted majority
• Fair MPC Framework
• Summary & extensions
06/09/04
Fair MPC
22
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)
Honest parties reveal their secrets, and corrupted parties
abort (and learn the result).
06/09/04
Fair MPC
23
FCPFO : Commit-Prove-Fair-Open
• Commit phase: Every party Pi commits to a value xi.
• Prove phase: Every party Pi proves a relation about xi.
• Open phase: Open x1, x2,…, xn simultaneously.
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.
06/09/04
Fair MPC
24
Time-lines: Towards realizing FCPFO
head
tail
accelerator 1
accelerator 2
…
accelerator k
• A time-line: An array of numbers (head, …, tail).
• Time-line commitments:
–
–
–
–
06/09/04
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.
Fair MPC
25
A time-line, mathematically
accelerator 1
g
g
k-1
2
2
[BN00,GJ02,GP03]
accelerator 2
g
…
…
k-1+2k-2)
(2
2
g
k
2
2
• 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 =
06/09/04
2
g2
k
Fair MPC
26
A time-line, mathematically (cont’d)
accelerator 1
accelerator 2
…
g
… g
g
g
• C • Can move forward m positions by doing m squarings.
2i
2
• • Knowing (N), one can compute G[i] = g efficiently, for any i.
k-1
2
2
k-1+2k-2)
(2
2
k
2
2
• • 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).
06/09/04
Fair MPC
27
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
06/09/04
Fair MPC
28
Fair exchange using time-lines (cont’d)
Alice
Bob
t
2t
• ABORT: If Bob aborts and force-opens in t steps, Alice can do it as
well in 2t steps.
06/09/04
Fair MPC
29
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 Pi reveals 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.)
06/09/04
Fair MPC
30
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 FCPFO can be realized efficiently
• Efficient and fair solution to the Socialist Millionaires’ Problem
(aka PET — remember the authentication problem?)
06/09/04
Fair MPC
31
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, 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).
Note: FMPC only provides the possibility of having fair ideal
functionalities. Always possible to have unfair functionalities/
protocols.
06/09/04
Fair MPC
32
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.
06/09/04
Fair MPC
33
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…
06/09/04
Fair MPC
34
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).
06/09/04
Fair MPC
35
“Time is on my side —
yes it is”
Juan Garay
Bell Labs – Lucent Technologies