Try   HackMD

(DRAFT) Garbled Circuits for Three-Party Computation

Imagine a group of people have some private data, and they want to jointly compute a function of their private data, without sharing any of the data. Maybe they want to know the median of their salaries, without anyone revealing their own. Maybe a group of doctors wants to collaborate on a statistical study, without sharing any data about individual patients. This is the problem that multiparty computation solves.

If you haven't thought about this before, you'll want to start with the special case of two-party computation, which rests on Yao's garbled circuits protocol and a technique called oblivious transfer. This post by Gubsheep walks you through understanding how you would discover the protocol on your own. If you just want to see the protocol, Vitalik's post is also very good.

In this post I'm going to explain how to upgrade two-party computation to handle computations between three (or more) people, still using the basic idea of garbled circuits.

For this post, we're going to assume that all three parties carry out the protocol honestly One could ask for stronger security guarantees. There are lots of different 3PC protocols, with different tradeoffs among security and complexity. There are also lots of good ideas that we won't get into in this blog post for example, "cut-and-choose".

A three-party version of oblivious transfer

Alice has 4 messages:

m00,m01,m10,m11. Bob and Carol each have a private bit call them
b
and
c
. Alice wants to transmit
mbc
to Carol, in such a way that:

  • Alice learns neither
    b
    nor
    c
  • Bob learns neither
    c
    nor any information about the messages, and
  • Carol learns neither
    b
    nor any information about the other three messages.

If you've seen plain vanilla two-party oblivious transfer, it's not hard to come up with a protocol. Here's one:

  • Alice randomly generates four symmetric encryption keys two for Bob (
    Bobkey0
    and
    Bobkey1
    ) and two for Carol (
    Carkey0
    and
    Carkey1
    ).
  • Alice performs a classical (two-party) oblivious transfer with Bob, sending him
    Bobkeyb
    ; Alice performs another OT with Carol, sending her
    Carkeyc
    .
  • Alice sends Bob this table.
(b, c)
(0, 0)
EncBobkey0(EncCarkey0(m00))
(0, 1)
EncBobkey0(EncCarkey1(m01))
(1, 0)
EncBobkey1(EncCarkey0(m10))
(1, 1)
EncBobkey1(EncCarkey1(m11))
  • Bob uses
    Bobkeyb
    to decrypt the two messages
    EncCarkey0(mb0)
    and
    EncCarkey1(mb1)
    , and sends them both to Carol.
  • Carol uses
    Carkeyc
    to decrypt the one message
    mbc
    .

Why is this secure?

  • Alice doesn't learn anything about
    b
    and
    c
    because nobody sends her any messages (except as part of the original OT protocol, which we know is secure).
  • Bob doesn't learn anything about
    c
    because Carol never sends him any messages. He doesn't learn anything about any of the encrypted messages
    mij
    because he doesn't know
    Carkey0
    or
    Carkey1
    .
  • Carol doesn't learn anything about
    b
    because she only sees
    EncCarkey0(mb0)
    and
    EncCarkey1(mb1)
    . She doesn't learn anything about the two messages
    mi0
    and
    mi1
    for
    ib
    because she never sees them, even in encrypted form; she doesn't learn the third message
    mbk
    for
    kc
    because she doesn't have the key to decrypt it.

Toward a 3PC Protocol

Let's make a couple of observations.

  • What if Bob and Carol each have 2 bits (
    b0,b1,c0,c1
    ), Alice has
    24=16
    messages (
    m0000,m0001,,m1111
    ), and Alice wants to send Carol only the single message
    mb0,b1,c0,c1
    determined by Bob's 2 bits and Carol's 2 bits?

To make this work, Alice needs to give Bob (and Carol, but we'll focus on Bob for now) a

Bobkey for each of his two bits. So Alice chooses at random 4 symmetric keys,
Bobkey0,0,Bobkey0,1,Bobkey1,0,Bobkey1,1
. Using two OTs, Alice transfers to Bob the key
Bobkey0,b0
corresponding to his first bit and the key
Bobkey1,b1
corresponding to his second bit. Now Bob computes a symmetric key
Bobkey=Hash(Bobkey0,b0,Bobkey1,b1)
. Alice does the same with Carol.

Now there are four possibilities for

Bobkey and four possibilities for
Carkey
, and Alice knows all of them. So Alice can publish a table just like the table above, but with 16 rows and at the end of the protocol, Carol learns only the one value she's supposed to.

In the actual protocol, Bob has 3 bits

(b0,b1,b2), Carol has 2 bits
(c0,c1)
, and Alice's table has
25=32
rows.

Secret shares

Just like in the 2PC protocol, each bit

xi each "wire" in the circuit will be jointly held by Alice, Bob, and Carol, in the form of "secret shares". In other words: Alice will hold a bit
ai
, Bob
bi
, and Carol
ci
, with the property that
aibici=xi
.

In our protocol, Alice and Bob will choose her bit

ai at random. We might as well as choose Bob's shares
bi
of gate output bits by simply setting them all equal to
b1
, Bob's first input bit. (This lets Alice send Bob his keys without using extra oblivious transfers.) And then
ci
will be determined from the inputs to the gate,
ai
and
bi
, by the rule
ci=aibixi
.

The Protocol

Just as in the usual 2PC garbled circuits protocol, Alice sets up the initial "garbling" of the circuit.

We set up some notation first. Number Bob's inputs

b1,,bm and
cm+1,,cm+r
. Number the gates
Gm+r+1,,Gm+r+n
, in some order (so that the inputs to each
Gi
are either inputs to the circuit, or outputs of previous gates).

Let's call all the bits (wires) in the circuit

x1,,xm+r+n. So
x1,,xm
is just another name for Bob's inputs
b1,,bm
, and similarly for Carol's inputs. We'll call
ai,bi,ci
the three parties' shares of the bit
xi
.

  • For each gate
    Gi
    , Alice chooses at random her share
    ai
    of the output bit
    xi
    .
  • For each bit to be held by either Bob or Carol (this includes both their input bits to the circuit, and their shares of intermediate bits
    xi
    ), Alice chooses at random two keys, one for each value of the bit. So: for each
    bi
    , Alice chooses
    Bobkeyi,0
    and
    Bobkeyi,1
    . Similarly for Carol's bits
    ci
    .
    • For Bob's shares of output bits, since we know
      bi=b1
      , we'll just use the same keys for Bob. So
      Bobkeyi,b=Bobkey1,b
      .
  • For each gate
    Gi
    , Alice makes a 32-row table. Let
    xj
    and
    xk
    be the inputs to gate
    Gi
    . Then the table has the form:
(b_i, b_j, b_k, c_j, c_k)
EncHash(Bobkeyi,bi,Bobkeyj,bj,Bobkeyk,bk)(EncHash(Carkeyj,cj,Carkeyk,ck)(ci:=xiaibi,Carkeyi,ci)).
  • For each of Bob's and Carol's inputs

    bi and
    ci
    , Alice sends Bob and Carol the keys
    Bobkeyi,bi
    and
    Carkeyi,ci
    by oblivious transfer this is one OT per input bit to the circuit. (Note that Bob knows his keys for the whole circuit now, since they are all the same as his key
    Bobkey1,b1
    .)

  • Bob goes through each gate

    Gi in order and uses his known key to decrypt the 4 rows of the table with his known values
    bi,bj,bk
    . Bob then sends to Carol the 4 encrypted values
    EncHash(Carkeyj,cj,Carkeyk,ck)(ci:=xiaibi,Carkeyi,ci).

  • Carol goes through the gates in order. For each gate

    i, she uses the known keys
    Carkeyj,cj,Carkeyk,ck
    to decrypt both
    ci
    and
    Carkeyi,ci
    .

  • In the end, Carol computes her output bit

    cn. She, Alice and Bob share their three bits
    an,bn,cn
    to determine the final output
    xn=anbncn
    .

Security

First of all, notice that until the very last step information only ever travels from Alice > Bob > Carol. So (if the three parties don't communicate outside the protocol) Alice can't learn anything about Bob's or Carol's inputs, and Bob can't learn anything about Carol's.

Bob doesn't learn anything about Alice's inputs, either, since he only ever sees encrypted messages. And Carol only ever learns the bits

ci, which are guaranteed to be uniformly random, because they are computed by
ci=aistuff
, and
ai
is chosen uniformly at random.

But there's a more interesting question: If two of Alice, Bob and Carol team up, can they learn the third person's inputs?

Alice and Bob can't learn anything about Carol's inputs, because Carol never sends them any messages.

What can Bob and Carol learn? Even if they collaborate, they can't possibly learn more than the one row from each table. So they can learn

bi and
ci
for each
i
, but again that tells them nothing they didn't already know, because Bob chose
bi
and
ai
is random.

Alice and Carol can learn something, though. If Carol tells Alice which row of the table Bob sent her, Alice can work out Bob's bit

bi. But
bi
was the same as Bob's input bit
b1
. Even worse, once they know
b1
, they can figure out
xi
for every
i
.

Things get even worse if the players don't carry out the protocol honestly. Bob and Carol are constrained by the encryption: they only ever find out one key per bit, so they can only read the "correct" row of the table. But our protocol relies on Alice to garble the circuit correctly in the first place. Nothing stops a malicious Alice from writing any circuit she pleases.

We'll leave this as an example of a 3PC protocol and the level of security it affords but if you want to know more, read about the "cut and choose" method.