A Framework for Fair (Multi-Party) Computation Juan Garay (Bell Labs) Phil MacKenzie (Bell Labs) Ke Yang (CMU)

1
A Framework for Fair(Multi-Party)
ComputationJuan Garay (Bell Labs)Phil
MacKenzie (Bell Labs) Ke Yang (CMU)
2
Talk Outline

• Multi-party computation (MPC) example Fair MPC
• Fairness definition(s)
• Fair protocols with corrupted majority
• Fair MPC Framework
• Summary extensions

3
Secure Multi-Party Computation (MPC)

• Multi-party computation (MPC) Goldreich-Micali-Wi
  gderson 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 n2

Studied for a long time. Focus has been security.
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 lt 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).

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

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)

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.

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

9
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 appns (e.g.,
two-party contract signing, fair exchange,).


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.

11
Security ? Fairness
On-line Bidding Function if (seller.price lt
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.
12
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!
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

14
Unfortunately

• Fairness is impossible with corrupted majority (t
  ? n/2)

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.

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

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

17
Previous Security Definitions

• A typical gradual release protocol (e.g., BN00,
  GP03, P03) consists of two phases
• Computation phase Normal computation.
• Revealing phase Each Pi gradually reveals a
  secret si then each Pi computes
  the result y from s1, s2,, sn.

18
Previous Security Definitions (contd)
Definition is not in the simulation paradigm
Suppose A aborts early and doesnt have
enough time to find y. Then S shouldnt
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


19
Simulation Paradigm and Fairness

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

20
Our Security Definition

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

Timed protocol ?T ?t, parameterized by
the adversarys 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 .

21
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 partys 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 (abort-
• free ) running time of ?t is a fixed poly.
  independent of t.

22
Talk Outline

• Multi-party computation (MPC) example Fair MPC
• Fairness definition(s)
• Fair protocols with corrupted majority
• Fair MPC Framework
• Summary extensions

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


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.

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.


25
Time-lines Towards realizing FCPFO

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.

26
A time-line, mathematically BN00,GJ02,GP03

accelerator 1
accelerator 2

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

• N safe Blum modulus,
• N pq, where p, q, (p-1)/2, (q-1)/2 are
  all primes.
• g a random element in ZN.
• head g, tail g22k

27
A time-line, mathematically (contd)

accelerator 1
accelerator 2

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

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

• Knowing ?(N), one can compute Gi g22i
  efficiently, for any i.

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

Alice
Bob
29
Fair exchange using time-lines (contd)
Alice
Bob

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

30
Realizing FCPFO using time-lines

• Setup A master time-line T ?N g Gj,
  j1,,k? in CRS.
• Commit Each party Pi
• Derives a time-line Ti ?N gi Gij?
• TL-commits to xi (gi Gik xi),
• Prove Standard ZK proof.
• Open In round m, each party Pi reveals Gim
  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.)

31
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?)

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


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

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

35
Summary Extensions (contd)

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

36
Time is on my side yes it isJuan
GarayBell Labs Lucent Technologies