A Framework for Fair(Multi-Party) Computation

Juan Garay (Bell Labs)Phil MacKenzie (Bell Labs)

Ke Yang (CMU)

06/09/04 Fair MPC 2

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 3

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 4

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 5

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 Ff performs the computation.

Parties P1, P2, …, Pn (some corrupted), each holding private input xi, wish to compute y = f(x1, x2,…, xn) privately and correctly.

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

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 7

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

06/09/04 Fair MPC 8

“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 9

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 P1, P2, …, Pn (some corrupted), each holding private input xi, wish to compute y = f(x1, x2,…, xn) 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,…).

06/09/04 Fair MPC 10

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

06/09/04 Fair MPC 11

Security Fairness

On-line Bidding Functionif (seller.price <= buyer.price), then return (seller.price + buyer.price)/2else 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 12

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 13

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 14

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

06/09/04 Fair MPC 15

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.

06/09/04 Fair MPC 16

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”

06/09/04 Fair MPC 17

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 18

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.

06/09/04 Fair MPC 19

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 20

Our Security Definition

• Our approach: Allows to depend on the running time of A.

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

Timed protocol [T] = {[t]}, parameterized by the adversary’s running time. Each [t] is a “normal” protocol for each t.

06/09/04 Fair MPC 21

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

06/09/04 Fair MPC 22

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 23

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)

Unfai

r!

Honest parties reveal their secrets, and corrupted parties abort (and learn the result).

06/09/04 Fair MPC 24

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.

Using FCPFO, the revealing phase becomes fair, and so does theMPC protocol.

Simultaneous opening guarantees fairness — either all parties learn all the committed values, or nobody learns anything.

06/09/04 Fair MPC 25

Time-lines: Towards realizing FCPFO

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

…head tail

accelerator 1 accelerator 2 accelerator k

06/09/04 Fair MPC 26

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 ZN*.

• head = g, tail = g22k

g22kg g22k-1

g2(2k-1+2k-2) …

accelerator 1 accelerator 2 …

06/09/04 Fair MPC 27

A time-line, mathematically (cont’d)

g22kg g22k-1

g2(2k-1+2k-2) …

accelerator 1 accelerator 2 …

• C • Can move forward m positions by doing m squarings.

• Difference: New “Yet-More-General BBS Assumption” (YMG-BBS).

06/09/04 Fair MPC 28

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

06/09/04 Fair MPC 29

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

06/09/04 Fair MPC 30

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 31

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 FCPFO can be realized efficiently

• Efficient and fair solution to the Socialist Millionaires’ Problem (aka PET — remember the authentication problem?)

Plug FCPFO into existing MPC protocols Fair MPC protocols

06/09/04 Fair MPC 32

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.

06/09/04 Fair MPC 33

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

06/09/04 Fair MPC 34

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 35

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

“Time is on my side —yes it is”

Juan GarayBell Labs – Lucent Technologies