 Hi, my name is David Heap. In this talk, I'll be talking about our paper, Stacked Garbling, Garbled Circuit Proportional to Longest Execution Path. This is work done by myself and my advisor, Vlad Kolesnikov, and the two of us work at Georgia Tech in Atlanta, Georgia. So as some background for this work, I'll be discussing Yale's Garbled Circuit, which is an efficient protocol that allows two parties to securely compute an arbitrary function of their inputs. What I mean by securely compute is that the two party provide private inputs and we're nothing except for the function output, that is, their private input is protected. The reason that we like garbled circuits is because it is often the most efficient technique for secure two party computation. So in particular, Garbled Circuit is a constant round protocol, and this means that we don't have to suffer from high network latency. Of course, it's always interesting to try to make protocols more efficient and that's what we achieve in this work. So in Yale's Garbled Circuit, communication in terms of bandwidth is the bottleneck. So specifically, one player, the so-called circuit generator, has to produce a large encryption of the circuit that represents their function and then send this encryption over the network to the so-called circuit evaluator. And is this simple sending of an encryption from one player to the other that is the bottleneck of the entire protocol? So reducing the size of this encryption is a very interesting direction of research. In this work, we show that we can take advantage of conditional branching that occurs in the source program. So for instance, if your function has some sort of if statements or switch statements in it, then we can take advantage of this exclusive conditional behavior that only one of these branches is actually evaluated in order to reduce the total amount of bandwidth that we consume. Traditionally, it has been assumed that we need communication proportional to the entire circuit, that is including all of the different conditional branches because we need to ensure security, meaning that the players have to do something symmetric with respect to the different branches. We'll see that in this talk. And so the simplest way to achieve this is to have them simply run garbled circuit for all of the branches and then resolve which branch was actually taken afterwards. In this work, we show that there are some cryptographic techniques that you can use to reduce the amount of communication such that it's proportional only to the single longest execution path. That is, if you have 100 different conditional branches, you don't need to pay for all of them in terms of communication. You only need to pay for the single longest branch. I'd like to begin by reviewing some of the basics of garbled circuit such that later on we can extend these basics with the principles evolved with stacked garbled. Garbled circuit relies on giving the two players two separate roles. So here we'll allow Alice to be the so-called circuit generator. Circuit generator's job is to build an encryption of the entire circuit which he then sends across the wire to Bob, the so-called circuit evaluator. The evaluator's job is to step through this encrypted circuit gate by gate, propagating encryptions of input values to encryptions of output values such that the semantic values on the wires are propagated through the circuit but it's also such that he does not learn what any of these semantic values actually are. He only gets to see encryptions of all the values. Once Bob has walked all the way through the circuit from getting to end and obtained encryptions of output values, the two players work together to decrypt these output values and learn the output of the function. So in more detail, let's start by looking at what the circuit generator does. First, Alice is going to select pseudo random wire labels for each of the wires in the circuit. So here I have these depicted as keys and this is significant because we will use these keys to encrypt logical truth tables as we will see. Each wire has two different keys, a red key and a green key, which correspond to a logical zero and logical one respectively. The idea is that later when Bob evaluates the circuit, he will only have one key per wire and furthermore, he will be unable to distinguish which color key he has. Alice uses these keys to encrypt the logic of each of the gates in the circuit. So let's just look at one gate, this AND gate here. So this AND gate has a particular truth table corresponding to its semantics. Alice constructs an encrypted version of these semantics by looking at each row of the truth table and for each output of the truth table, she will place a corresponding output key. So you can see here that she has placed corresponding the outputs of this logical truth table, a red key where a zero appears and a green key where a one appears. She then encrypts the outputs of these keys using the corresponding input keys. Now so far, this is not yet secure. Later when Bob gets input keys corresponding to this table, he will decrypt a particular row. But right now we have these rows in a particular order such that if Bob knew to decrypt, say, the second row, he would know which input keys he has and also which output he has. So we break this ordering from the semantic meaning by just randomly permuting the order of the rows. And now we're done. We've encrypted the logic of this particular gate. Alice continues doing this forever gate in the circuit and generates all of these collections of encryptions of truth tables which we collectively refer to as the material. This material is the stuff that Bob needs to walk through the circuit gate by gate in order to decrypt output keys. Now, for the purposes of this talk, I actually would like to abstract a bit and I'd like for you to think of these encrypted truth tables as random strings. That is specifically from the perspective of Bob when he receives these encrypted truth tables, he cannot see any of the structure that they have. Instead, they just appear to be random strings which he then interprets as encrypted truth tables. As we will see later on, this turns out to be very significant because it means that Bob cannot distinguish when an encryption of a circuit is properly constructed versus when it is not. So Alice takes all of these encryptions of truth tables, compiles this into a single string of material and sends it across the wire to Bob. I'd like to re-emphasize that this simple sending of the material from Alice to Bob is the most expensive part of Garbled Circuit Protocols. And it is this communication, this bandwidth consumption that we reduce in this work. Now, let's look at how Bob uses this material to finish the Garbled Circuit Protocol. Again, Bob now has access to all of the material and though I won't discuss this at length, he also is able to get access to keys corresponding to the player's input values, which is primarily achieved via oblivious transfer. From here, Bob simply walks through this circuit gate by gate, decrypting the logical truth tables we constructed earlier according to the keys that he has. So he propagates the keys from input wires to output wires. Now that he has keys corresponding to the circuit output wires, he and Alice can work together to decrypt the semantic values of these keys. And this completes a basic version of the Alice Garbled Circuit Protocol. To review, the circuit generator's job is to encrypt the circuit gate by gate and ultimately to build this large string of material. Again, I'd like you to think of this material as being random looking, especially from the perspective of Bob, the evaluator. The evaluator then uses this material to evaluate the circuit gate by gate, decrypting the individual encrypted truth tables. By doing so, the players are able to propagate encryptions of input truth values to encryptions of output truth values, and therefore to securely evaluate the function. Finally, the dominant cost in the Alice Garbled Circuit is this string of material that is sent from generator to evaluator. Again, our goal is to just simply decrease the length of this string, which we do by taking advantage of conditional branching in the circuit. The subject of this work, again, is to explore how to make Garbled Circuit more efficient. The prior work has also looked at this problem, decreasing communication bandwidth due to Garbled Circuits. The primary way that people have improved the protocols is to decrease the number of encryptions needed to encode the semantics of an individual gate. Due to these improvements, Garbled Circuit today is efficient even for circuits with large numbers of gates. However, I'd like to point out that encrypting each gate individually leaves some efficiency on the table, in particular with respect to conditional branching. We individually encrypt all of the conditional branches of a circuit and send them across the wire, while in fact, almost none of the work involved with conditional branching is actually needed. That is, the output encryptions of all, except for one conditional branch, are completely discarded. So when we encode conditional branches into circuits, we waste a lot of work. It is this fact that we exploit in our work. We show a way to take advantage of this conditional branching such that we do not have to produce separate encryptions of all the branches. Two prior works have also looked at the same problem, how to reduce the amount of communication for a Garbled Circuit in the case of conditional branching. So pre-if, due to my advisor, Black Kolesnikov, asked the question, how can we reduce communication if the circuit generator happens to know the control flow path through the program? That is, the generator knows all of the conditional branching decisions that are made. Symmetrically, Vlad and myself asked, what can we do if the evaluator knows which branch is taken? But in this work, we ask a more difficult question. We use some of the key ideas from these two prior works and ask the question, what if no one knows which branch is taken? So this brings us to our approach of stacked Garbled. So it is no longer sufficient to consider only one circuit, of course, since we're considering conditional branches. So for the purposes of this talk, we'll discuss two circuits. Now, I'd like to start by emphasizing that we place no requirements on the structure of these circuits. They can in particular have different gates and completely different topologies. The circuits need not even be of the same number of gates. Now, with that said, I want to abstract and forget about the details of the circuit and simply think of these as objects that can be encrypted. An initial question is to ask, what does it mean that neither player knows which branch is taken? The answer that we adopt is that the so-called branch condition which controls which branch is taken must be the output of some prior Garbled circuit. So here we have three circuits which we will compose together. And it is this wire which is going to instruct which of the two conditionally composed circuits, C1 and C2 should be evaluated. I'd like to quickly show how this would be done in a naive fashion that is without stacked garbling. The idea is simple. We just route the output wires of this prior circuit to both of our conditional branches, evaluate both circuits in their entirety and then add a special circuit at the end which we call a multiplexer. The multiplexer's job is simply to select out the output of the branch that was actually taken. I'll now show how we improve over this naive approach by compacting the amount of material that is needed first circuits that include conditional branching. As one final piece of background, I'd like to discuss the notion of expanding a circuit encryption starting from a seed. If we recall, Alice's first job was to select random keys for all of the wires in the circuit. In this work, we insist that she does so according to a pseudo random seed. From this point forward, all of Alice's actions in constructing the circuit encryption are completely deterministic. And so what this means is that the pseudo random seed has become a compact description of the entire circuit encryption. Of course, we cannot use this seed as the encryption of a circuit in all cases. The problem is that if we just send this seed from Alice to Bob, then Bob will get to see all of the keys on all of the wires and this is simply not secure. He gets far too much information. However, in this work, we show that in the case of branches not taken, it is okay for the encryption of one of these untaken branches to be derived from a seed that Bob is allowed to know. So now for our approach. Again, we have some circuit C prime that is feeding outputs into the two branches C1 and C2. We start by simply constructing an encryption of this first circuit M prime. But for the branches, Alice will perform differently. We will have her construct encryptions of these two circuits according to pseudo random seeds to build up two strings of material M1 and M2. Again, recall that these strings of material are encryptions of truth tables, but they can be regarded as nothing more than random looking strings. Recall that we have a branch condition that is either zero or one and that there are keys available which encode these two different values. What we will do is have the circuit generator construct encryptions of the two seeds in an encrypted truth table. That if Bob gets access to the green key, then he should be allowed access to seed one. And if he gets access to the red key, he should be allowed access to seed two. What this will do is allow Bob to construct an encryption of the branch that is not taking. Like our encrypted truth tables from earlier, we need Alice to randomly permute the order of these seeds such that Bob cannot correlate the thing that he decrypts with some semantic meaning in the circuit. Next, Alice is going to package up the material to send over to Bob. So she collects M prime and also this encrypted truth table, including seeds. But instead of sending M one and M two separately, she adds these two values together using bitwise exclusive or. Here is where we have one in terms of communication. In the naive approach, we would send M one and M two separately, but now we are sending the X or some of these two values. Alice sends this, all of this material across the wire to the evaluator. So now in the evaluator's view, the evaluator has access to the sum M one plus M two and to M prime. And also by evaluating C prime, he gets some branch condition. In this case, we'll say he gets a green key meant to indicate that the circuit C two is taken. Of course, Bob is not supposed to know which branch is taken. We will revisit that in a moment. For now, let's suppose magically Bob has figured out which circuit is meant to be taken. What he can do from here is decrypt a seed from this encrypted truth table of seeds and use the seed to re-encrypt the branch not taking, that is to regenerate the string M one. Now he can use bitwise X or once again to extract the string M two. From here, it's a simple manner to feed in the correct inputs and derive output keys by evaluation. Of course, as I have described so far, there is a problem because the evaluator is not supposed to know which branch is actually taken. The way that we resolve this is to ensure that Bob's actions are symmetric. That is, he does not know that the second circuit is taken, he simply guesses if that's the case. And symmetrically, he also guesses that the first circuit is taken. So to describe what happens when he makes this second guess, well, he uses the seed as before, but instead of trying to encrypt C one, he tries to encrypt C two. Notice that this action of encrypting C two has nothing to do with any action taken so far by the circuit generator. The circuit generator never encrypted the circuit C two using seed one. So instead of getting something that the generator had generated, the evaluator generates a new encryption M two star. When the evaluator then goes to try to extract the material M one, he is unsuccessful. That is, this algebraic expression does not reduce. So instead of having an encryption corresponding to circuit one, the evaluator has an encryption corresponding to nothing at all. This bit string of material is simply garbage. Here it is significant that these strings of material look random. You see, when the evaluator obtains this string of material, this large sum, it's critical that he cannot distinguish this is not a valid encryption. Thus, when the evaluator tries to run this circuit using this invalid encryption, he inevitably ends up with some output labels that are neither an encryption or zero over one. The output labels are simply garbage as well. From here, we would like to get rid of the garbage output labels. We want to discard the garbage and retain the valid output labels that came from the actually taken branch. And we want this to all happen obliviously. One way that this could be done is to involve some sort of protocol. This is the approach that was taken in the free if paper. The idea is that the two players will communicate using some sort of protocol involving oblivious transfer in order to discard the garbage and yield only re-encrypted versions of the output keys from the taken branch. This is somewhat unsatisfying. Recall that one of the primary advantages of garbled circuits is its constant round property. By incorporating a protocol to eliminate garbage, we are losing the fact that we have constant rounds. The number of rounds are now proportional to the number of conditional branches. Therefore, we developed a way to discard this garbage completely non-interactively. This is perhaps the most technically involved and confusing part of our approach. So I hope that if you have trouble with this explanation, you'll take a look at our paper. But the idea is that the generator is going to do some extra work in order to build a garbled circuit gadget, which when decrypted will yield only the valid output labels and will discard all of the garbage. At a high level, Alice is going to put herself in the shoes of Bob when he makes one of these assumptions that is bad. So specifically what she will do is she will use seed one to encrypt seed two. Recall that this is not consistent with the way that she built her circuit encryption. This corresponds to a bad assumption made by Bob about which branch is taken. Therefore, by running the circuit C1 using the same garbage material as Bob did, she can arrive at the same garbage output labels that Bob did. And symmetrically, she can perform the same exact actions to derive the garbage output labels from seed two. Now Alice knows the garbage output labels from both circuits as well as the valid output labels. This amount of information suffices for her to build a garbled gadget. This garbled gadget is simply a large encrypted truth table which when provided inputs that are either garbage or valid values will throw away the garbage values and retain the valid ones. There is one small problem with what I have depicted so far which is that the number of garbage values that the evaluator could arrive at is exponential in the number of inputs. To resolve this, we add one additional component which is this front de-multiplexer. This de-multiplexer component is simple. Its job is to make sure that the inputs that Bob uses for the branch is not taken are predictable. You can think of what it is doing is it is multiplying all of the inputs to each branch by either zero or one depending on if the branch is taken or not. By doing so, we eliminate uncertainty about these output garbage values. There's simply only one of them that can possibly come out of each circuit. With this in hand, it is now practical for Alice to build one of these multiplexer components based on the values that come out of invalid execution of circuits. So this was stacked garbled. Again, our contribution is to reduce the amount of material sent from the circuit generator to the evaluator in Yau's Garbled Circuit Protocol. Our communication is constant in the number of conditional branches, theoretical improvement over prior work. As some future work, we're interested in reducing the computation overhead of our approach. Although I didn't discuss it, the procedure that of Alice putting herself in the place of Bob incurs quadratic work in the number of branches. We're interested in approaches which improve on this. As of now, we know a technique that improves this computation overhead to only O of B log B. We're very much interested in any approaches that can further improve this computation. So this was stacked garbling. Thank you very much for your time and for listening.