Secure multi party computation
Download
1 / 49

Secure Multi-Party Computation - PowerPoint PPT Presentation


  • 359 Views
  • Updated On :

Secure Multi-Party Computation. Oded Goldreich Presented by Chun Liu Nov 2001. Motivation.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Secure Multi-Party Computation' - medwin


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Secure multi party computation l.jpg

Secure Multi-Party Computation

Oded Goldreich

Presented by Chun Liu

Nov 2001


Motivation l.jpg
Motivation

  • Multiparty secure computation allows N parties to share a computation, each learning only what can be inferred from their own inputs and the output of the computation. For example, the parties can compute summary statistics on their shared transaction logs, including cross-checking of the logs against counterparties to a transaction, without revealing those logs.

CSE 597E


An example dining cryptographer problem l.jpg
An Example: Dining Cryptographer Problem

  • Three cryptographers are sitting down to dinner at their favorite three-star restaurant. Their waiter informs them that arrangements have been made with the Nittany Lion Inn for the bill to be paid anonymously.

  • One of the cryptographers might be paying for the dinner, or it might have been NSA (U.S. National Security Agency). The three cryptographers respect each other's right to make an anonymous payment, but they wonder if NSA is paying.

CSE 597E


Casting cryptographic problem l.jpg
Casting Cryptographic Problem

  • Specifying a random process which maps m inputs to m outputs.The inputs to the process are to be thought of as local inputs of m parties, and the m outputs are their corresponding local outputs.

  • Dining cryptographer problem is the simplified version, where the m outputs are identical.

CSE 597E


In plain english l.jpg
In Plain English

  • The problem of secure multi-party function computation is as follows: n players, P1,P2,…Pn, wish to evaluate a function , F(x1,x2,…xn), where xi is a secret value provided by Pi. The goal is to preserve the privacy of the player's inputs and guarantee the correctness of the computation.

CSE 597E


Trusted third party presents l.jpg
Trusted Third Party Presents

  • This problem is trivial if we add a trusted third party T to the computation. Simply, T collects all the inputs from the players, computes the function F, and announces the result. (This is the way we usually have elections, where the voters are the players and the trusted third party is the government). In general, we define secure multiparty computation as any protocol in an ideal scenario with a ‘trusted party’, and define a real life protocol as secure if it is ``equivalent'' to a computation in the ideal scenario.

CSE 597E


No trusted third party l.jpg
No Trusted Third Party

  • We show that whatever can be computed in this ideal scenario can be computed in a secure manner when no such trusted party exists.

  • Two types of “faulty” behaviour by the players.

    • we assume that players always follow the protocol but may collaborate and try to learn additional information (private computation)

    • the general case where faulty players can collaborate in any way to gather information and disrupt the computation (secure computation).

CSE 597E


General two party computation l.jpg
General Two-Party Computation

  • Content

    • Semi-honest adversary.

    • Secure protocol with respect to Semi-honest Behavior.

    • Force parties to behave in a semi-honest manner.

CSE 597E


Definition l.jpg
Definition

  • Functionality: a random process which maps pairs of inputs (one per each party) to pairs of outputs (one per each party).

    • f: {0,1}*x{0,1}* {0,1}*x{0,1}*

    • For every input (x,y), the desired output-pair is a random variable f(x,y). The first party holding input x, wishes to obtain the first element of f(x,y), while the second party wishes to obtain the second one.

CSE 597E


Generic case l.jpg
Generic case

  • The first party hold a1, b1, and the second party holds a2, b2, where a1+a2 is the value of one input wire and b1 +b2is the value of the other input wire. What we want to provide each party with a “random” share of the value of the output wire; that is a share of the value (a1+a2)*(b1 +b2). That is:((a1+b1), (a2 +b2)) (c1, c2) Eq.1where c1+c2 = (a1+a2)*(b1 +b2) Eq.2

CSE 597E


The semi honest model l.jpg
The Semi-Honest Model

  • Semi-honest party

    • Follows the protocol properly

    • Keeps a record of all its intermediate computations.

  • Let f: {0,1}*x{0,1}* {0,1}*x{0,1}*, where f1(x,y) (resp. f2(x,y)) denotes the first element of f(x,y) and  be a two party protocol for computing f.

CSE 597E


Privacy w r t semi honest l.jpg
Privacy w.r.t Semi-Honest

  • During a execution of  on (x,y):

    • The view of the first party denoted by VIEW 1(x,y), is (x,r,m1,…,mt)

      • r, the outcome of the first party’s internal coin tosses.

      • mi, the ith message received.

    • The output of the first party denoted byOUTPUT 1(x,y).

CSE 597E


Privacy w r t semi honest13 l.jpg
Privacy w.r.t Semi-Honest

  • For a deterministic functionality f,  privately computesf if there exist polynomial-time algorithms S1 and S2, such that:

    • {S1(x,f1(x,y))}x,y{0,1}*c {VIEW 1(x,y)} x,y{0,1}*

    • {S2(x,f1(x,y))}x,y{0,1}*c {VIEW 2(x,y)} x,y{0,1}*

  • c Computational indistinguishable

CSE 597E


Privacy w r t semi honest14 l.jpg
Privacy w.r.t Semi-Honest

  • For a general case,  privately computesf if there exist polynomial-time algorithms S1 and S2, such that:

    • {S1(x,f1(x,y)), f2(x,y)}x,y c {VIEW 1(x,y), OUTPUT 2(x,y)} x,y

    • {f1(x,y), S2(x,f1(x,y))}x,yc {OUTPUT 1(x,y), VIEW 2(x,y)} x,y

CSE 597E


Secure protocol for semi honest l.jpg
Secure Protocol for Semi-Honest

  • Oblivious Transfer. Let k be a fixed integer, and let b1,b2,…bk{0,1} and i  {1,…k}, then OT1K is defined as

    • OT1K((b1,b2,…bk),i) = (,bi)

  • The first player, holding input (b1,b2,…bk) is called the sender and the second player holding the input i  {1,…k}, is called receiver.

CSE 597E


Secure protocol for semi honest16 l.jpg
Secure Protocol for Semi-Honest

  • Step S1: The sender uniformly select a trapdoor pair, (a,t) by running the generation algorithm, G, on input 1n. That is, it uniformly selects a random-pad r, for G and sets (a,t) = G(1n, r). It sends a to the receiver.

  • Step R1: The receiver uniformly and independently selects e1,e2,…ekDa, sets yi = fa(ei) and yj = ej, for every ji, and sends (y1,y2,…yk) to the sender

CSE 597E


Secure protocol for semi honest17 l.jpg
Secure Protocol for Semi-Honest

  • Step S2: Upon receiving (y1,y2,…yk), using the inverting-with-trapdoor algorithm and the trapdoor t, the sender computes xj=fa-1(yj), for every j {1,…,k). It sends (b1b(x1), b2b(x2),…, bkb(xk)) to the receiver.

  • Step R2: Upon receiving (c1,c2,…ck), the receiver locally outputs cib(ei)

CSE 597E


Circuit evaluation protocol l.jpg
Circuit Evaluation Protocol

  • Inputs: Party i holds the bit string xi1,…xin, for i=1,2

  • Step 1 – Share the inputs: Each party splits and shares each of its input bits with the other party, that is for every i=1,2, and j=1,…,n, party I uniformly selects a bit rij and send it to the other party as the other party’s share of input wire (i-1)*n+j, Party i sets its own share of the (i-1)*n+jth input wire to xij+rij .

CSE 597E


Circuit evaluation protocol19 l.jpg
Circuit Evaluation Protocol

  • Step 2 – Circuit Emulation: Proceeding by the order of wires, the parties use their shares of the two input wires to a gate in order to privately compute shares for the output wire of the gate. Suppose that the parties hold shares to the two input wires of a gate; that is Party 1 holds the share a1, b1 and Party 2 holds the share a2, b2,

    • Emulation of an addition gate: Party 1 just sets its share of the output wire of the gate to be a1+b1, so does Party 2.

CSE 597E


Circuit evaluation protocol20 l.jpg
Circuit Evaluation Protocol

  • Emulation of an multiplication gate: Shares of the output wire of the gate are obtained by invoking the oracle for the functionality of Eq. 1-2, where Party 1 supplies the input (query part) (a1, b1) and Party 2 supplies (a2, b2).

  • Step 3: Recovering the output bits: Once the shares of the circuit-output wires are computed, each party sends its share of each such wire to the party with which the wire is associated. Each party recovers the output bits by adding-up the two shares.

  • CSE 597E


    Forcing semi honest behavior l.jpg
    Forcing Semi-Honest Behavior

    • Possible Actions and Counter-Measures

    • Sub-protocols:

      • Input commitment

      • Coin-generation

      • Protocol Emulation

    • The Compiler itself.

    CSE 597E


    Forcing semi honest behavior22 l.jpg
    Forcing Semi-Honest Behavior

    • What a malicious party can do?

    CSE 597E


    Bkgd commitment scheme l.jpg
    BKGD: Commitment Scheme

    • Uniform family of probabilistic polynomial-size circuits {Cn}, satisfying:

      • Perfect Unambiguity: For every n, the supports of Cn(0) and Cn(1) are disjoint

      • Computational Secrecy: The probability ensembles {Cn(0)}nN and {Cn(1)}nN are computationally indistinguishable.

    • Can be constructed given any 1-1 one-way function.

    • Denote by Cn(b,r) the output of Cn on input bit b using the random sequence r.

    CSE 597E


    Bkgd strong proofs of knowledge l.jpg
    BKGD: Strong proofs of knowledge

    • R: binary relation V:efficient strategy

    • V is a strong knowledge verifier for R iff:

      • Exists an interactive machine P so that for every (x,y) R, all possible interactions of V with P on common-input x and auxiliary-input y are accepting.

      • Exists a negligible  : [0,1] and a probabilistic polynomial-time oracle machine K such that for every strategy P and every x,y,r  {0,1}*, machine K satisfies the following condition:

      • If p(x) > u(|x|) then Pr[(x, KPx,y,r(x)) R]>1- u(|x|)

    CSE 597E


    Sub protocol input commitment l.jpg
    Sub-protocol: Input Commitment

    • Goal: have Party 1 commit its input using commitment scheme {Cn}nN

    • Inputs: party 1 gets input (,r)  {0,1}{0,1}n, and party 2 gets input 1n.

      • Step C1: P1 sends c=Cn(,r) to P2.

      • Step C2: zero-knowledge strong-proof-of-knowledge. P1: prover and P2: verifier. Common input is c, prover gets auxiliary input (,r) with objective to prove that it knows (x,y) such that c=Cn(x,y).

      • Output: P2 sets its local output to c.

    CSE 597E


    Sub protocol coin tossing aug d l.jpg
    Sub-protocol: coin-tossing (aug.d)

    • Goal: providing Party 2 with a commitment to the coin-outcome obtained by Party 1, rather than providing it with coin outcome itself.

    • Inputs: both parties get security parameter 1n.

    • Step C1.1: P1 uniformly selects(j,sj){0,1}{0,1}n, sends cj=Cn(j,sj) to P2.

    • Step C1.2: The parties invoke a zero-knowledge strong-proof-of-knowledge so that P1 plays the prover and P2 plays the verifier. The common input to the proof system is cj, the prover gets auxiliary input (j,sj) and its objectives is to prove that it know (x,y) such that cj=Cn(x,y).

    CSE 597E


    Sub protocol coin tossing aug d27 l.jpg
    Sub-protocol: coin-tossing (aug.d)

    • Step C1.3: P2 uniformly selects ’j {0,1}, and send ’j to P1

    • Step C1.4: P1 set bj= ’j j

    • Step C2: P1 sets b=b0 and r=b1b2…bn, and sends c=Cn(b,r) to P2.

    • Step C3. The parties invoke a zero-knowledge proof system (P1: prover, P2:verifier). Common input (c0,c1,…,cn, ’1 ,’2,…,’n,c), the prover gets auxiliary input (’1 ,’2,…,’n,s0,s1,…,sn) w/ objective to prove there exists (x0,x1,…,xn, y0,y1,…,yn) such that:(j cj= Cn(xj,yj)) (c=Cn(x0’1 , x1’2,…,xn’n)

    • Step C4: P1 sets output to (b,r), P2 sets outputs c.

    CSE 597E


    Sub protocol authenticated computation l.jpg
    Sub-protocol: Authenticated Computation

    • Goal: given f :{0,1}*{0,1}*{0,1}* and h: {0,1}* {0,1}*, force P1 send f(,) to P2, where  is known to both,  is known to P1, h() is known to P2.

    • Implementation: having P1 send f(,) and then prove in zero-knowledge the correctness of the value sent (w.r.t the common input (h(),).

    CSE 597E


    Authenticated computation l.jpg
    Authenticated Computation

    • Step C1: P1 sends v= f(,) to P2.

    • Step C2: Invoke zero-knowledge proof system. P1 plays prover, P2 verifier. Common input (v,h(),), prover get auxiliary input  w/ objective to provex, s.t. (h()=h(x))(v= f(,))

    • Step C3: P2 sets local output to v.

    CSE 597E


    The compiler itself l.jpg
    The compiler itself

    • Goal: Give a protocol, , for the semi-honest model, the compiler produces a protocol, ’, for the malicious model.

    • Input: P1 gets input x=x1x2…xn{0,1}n and P2 gets input y=y1y2…yn{0,1}n

    • Three phases:

      • Input-commitment phase

      • Coin-generation phase

      • Protocol emulation phase

    CSE 597E


    Input commitment phase l.jpg
    Input-commitment phase

    • Each of the parties commits to each of its input bits using the input-commitment functionality.

    • P1 uniformly select p1i {0,1}n, playing P1 with input (xi, pi1), P2 playing P2 w/input 1n. P2 get output Cn(xi, pi1). Vice Versa.

    • Each party now holds a string which uniquely determine the n-bit long input of the other party, and holds an NP-witness for the value of input committed to by the sequence held by the other party.

    CSE 597E


    Coin generation phase l.jpg
    Coin-generation phase

    • The parties generate random-pad for the emulation of . Invoking the (augmented) coin-tossing functionality.

    • P1 playing P1 w/ input 1n, P2 playing P2 w/ input 1n. P1 gets a pair (ri1, wi1)and P2 gets Cn (ri1, wi1). P1 set the ith bit of the random-pad to be ri1, and record the NP-witness. P2 records Cn (ri1, wi1). Vice versa.

    • Each party obtains the bits of the random-pad to be held by it, whereas the other party obtains commitment to these bits. The party holding the bit also obtains the randomization used in these commitments, to be used as an NP-witness to the correctness of committed value.

    CSE 597E


    Protocol emulation phase l.jpg
    Protocol Emulation Phase

    • Use the authenticated-computation.

    • Sender playing the role P1, and receiver playing the role P2.

      • a = (z,rj), where rj= r1jr2j…rjc(n)

      • r = (p1j, p2j…pnj, w1j, w2j…wjc(n))

      • h(a,r) = (Cn (z1,p1j),Cn (z2,p2j)…Cn (zn,pnj), Cn (r1j,w1j),Cn (r2j,w2j)…Cn (rjc(n),wjc(n)))

      • = all previous message sent by the other party.

      • f = the computation which determines the message to be sent in .

    • Each party holds the corresponding output of the party in protocol .

    CSE 597E


    General multi party computation l.jpg
    General Multi-Party Computation

    • m-ary Functionality: a random process f which maps sequences of inputs (one per each party) to sequences of outputs (one per each party). Let m denote number of parties.

      • f: {{0,1}*}m {{0,1}*}m

      • For every i, the ith party initially holds an input xi, and wishes to obtain the ith element in f(x1,x2,…,xm)

    CSE 597E


    Mp the semi honest model l.jpg
    MP The Semi-Honest Model

    • As defined exactly as in the two-party case. i.e.

    • Semi-honest party

      • Follows the protocol properly

      • Keeps a record of all its intermediate computations.

    CSE 597E


    Two malicious models l.jpg
    Two Malicious Models

    • The first model where the number of parties which deviate from the protocol is arbitrary.

      • Treatment follows the one used in two-party case.

    • The number of parties which deviate from the protocol is strictly less than half.

      • Simpler than the above ones.

    CSE 597E


    Mp circuit evaluation protocol l.jpg
    MP circuit evaluation protocol

    • Inputs: Party i holds the bit string xi1,…xin, for i=1,…,m

    • Step 1 – Share the inputs: Each party splits and shares each of its input bits with the other party, that is for every i=1,…,m, and j=1,…,n, and every ki, party i uniformly selects a bit rk(i-1)n+j and send it to the party k as the other party’s share of input wire (i-1)*n+j, Party i sets its own share of the (i-1)*n+jth input wire to xij+ kirk(i-1)n+j .

    CSE 597E


    Mp circuit evaluation protocol38 l.jpg
    MP circuit evaluation protocol

    • Step 2 – Circuit Emulation: Proceeding by the order of wires, the parties use their shares of the two input wires to a gate in order to privately compute shares for the output wire of the gate. Suppose that the parties hold shares to the two input wires of a gate; that is Party i holds the share ai, bi, where a1,…,am are the inputs of the first wire and b1,…,bm are second.

      • Emulation of an addition gate: Party i just sets its share of the output wire of the gate to be ai+bi.

    CSE 597E


    Mp circuit evaluation protocol39 l.jpg
    MP circuit evaluation protocol

    • Emulation of an multiplication gate: Shares of the output wire of the gate are obtained by invoking the oracle for the functionality of Eq. 3.7-8, where Party i supplies the input (query part) (ai, bi).

  • Step 3: Recovering the output bits: Once the shares of the circuit-output wires are computed, each party sends its share of each such wire to the party with which the wire is associated. For i=1,..m, and j=1,..,n, each party sends its share of wire N-(m+1-j)*n+j to Party i. Each party recovers the corresponding output bits by adding-up the m shares.

  • Outputs: Each party outputs the bits recorded in Step 3

  • CSE 597E


    Mp forcing the semi honest model l.jpg
    MP Forcing the Semi-honest Model

    • Communication protocol:

      • Broadcast, each round only one party send a message which is received by all parties.

    • Sequence of transformation:

      • Precompiling a protocol 0, which computes in the point-to-point model, into a protocol ’0 which computes in the broadcast model.

      • Using the first compiler to transform ’0 into a protocol ’1 secure in first malicious model.

      • Using the second compiler to transform ’1 into a protocol ’2 secure in second malicious model.

      • Postcompiling the protocols ’1 and ’2 to use the standard point-to-point model.

    CSE 597E


    Forcing shm first malicious case l.jpg
    Forcing SHM: First Malicious Case

    • Input-commitment phase: each party commits to each of its input bits using multi-party version of the input commitment.

    • Coin-generation phase: The parties generate random-pads for each of the parties. These pads serve as the coins of the corresponding parties in their emulations of the semi-honest protocol. Each party obtains the bits of the random-pad, whereas the other parties obtains commitments to these bits.

    • Protocol Emulation Phase: The parties emulate the execution of the semi-honest protocol with respect to the input committed in the first phase and the random-pad selected in the second phase.

    CSE 597E


    Forcing shm second malicious case l.jpg
    Forcing SHM: Second Malicious Case

    • The sharing phase: Each party shares each bit of its input and random-pad, with all the parties. So that strict majority of parties can retrieve the bit.

      • If a party aborts the execution prior to completion of this phase, then the majority player will set its input and random-pad to some default value, and carry out the execution on its behalf.

      • If a party aborts the execution after this phase, the the majority players will reveal its input and random-pad, and will carry out the execution on its behalf.

    • Protocol emulation phase:The parties emulate the execution of original protocol w.r.t the input and random-pad in the first phase.

    CSE 597E


    The compiler for the second case l.jpg
    The Compiler for the Second Case

    • Inputs: party i get input xi{0,1}n and random-pad ri{0,1}c(n)

    • The sharing phase: Each party shares each bit of its input and random-pad, with all parties. i.e.

      • For i=1,..m, and j=1,..,n+c(n), party i invokes VSS playing role P1 with input (, 1n), where  is the ith bit of xiri. The other party playing roles P2..m with input 1n. Party i obtains output pair (pji, wji), and each other party k obtains a pair (skj,I,cji) so that skj,I are shares of a secret relative to Gm,[m/2]’s random-pad pji.and cji is a sequence of commitments of the bits of pji.

    CSE 597E


    The compiler for the second case44 l.jpg
    The Compiler for the Second Case

    • Protocol emulation phase:

      • a = (xi,ri)

      • r = ((p1i, w1i),(p2i,w2i),…(pn+c(n)i, win+c(n)))

      • h(a,r) = (Cn (p1i, w1i),Cn (p2i,w2i ),…(pn+c(n)i, win+c(n)))

      • = all previous message sent by the other party.

      • f = the computation which determines the message to be sent in .

      • The input with with the other parties are to enter to the authenticated-computation can be determined, in case the parties supply different values for (h(,r),), the majority value is used.

    • Output: each party holds the corresponding output of the party in protocol .

    CSE 597E


    Appendix l.jpg
    Appendix

    • Solutions to dining cryptographer problem

    • Authenticated Byzantine Agreement

    • Verifiable Secret Sharing

    CSE 597E


    Solution l.jpg
    Solution

    • Each cryptographer flips an unbiased coin behind his menu, between him and the cryptographer on his right, so that only the two of them can see the outcome. Each cryptographer then states aloud whether the two coins he can see--the one he flipped and the one his left-hand neighbor flipped--fell on the same side or on different sides. If one of the cryptographers is the payer, he states the opposite of what he sees.

    CSE 597E


    Solution contd l.jpg
    Solution (contd.)

    • An odd number of differences uttered at the table indicates that a cryptographer is paying; an even number indicates that NSA is paying (assuming that the dinner was paid for only once). Yet if a cryptographer is paying, neither of the other two learns anything from the utterances about which cryptographer it is.

    CSE 597E


    Authenticated byzantine agreement l.jpg
    Authenticated Byzantine Agreement

    • Synchronous point-to-point and signature scheme.

    • Phase 0: Party 1 sign its input and sends it to all parties.

    • Phase 1,…,m: Each honest party proceeds as follows:

      • It inspects the message received at phase i-1, which is admissible if all previous signature is verifiable. authentic v-message.

      • If the party finds such one, it will sign the message by appending its signature to it, and sends to all parties.

    • Each honest party evaluates the situation:

      • If both authentic-0 and authentic-1 message received, reports Party 1 is malicious.

      • If for a single v {0,1}, if received authentic-v message, it output v.

      • Never received an authentic-v message, reports party 1 is malicious.

    CSE 597E


    Verifiable secret sharing l.jpg
    Verifiable Secret Sharing

    • (Unfinished)

    CSE 597E


    ad