Yao's Garbled Circuits
Presentation: https://www.youtube.com/watch?v=-BT-Oyqy5vc
Last updated
Presentation: https://www.youtube.com/watch?v=-BT-Oyqy5vc
Last updated
Though Yao’s Garbled Circuits was first introduced in 1986, it still stands as the base for numerous multi-party computation (MPC) methods used today (i.e. ABY3). We'll go over the original concept of Yao’s Garbled Circuits and introduce a couple popular optimizations done on top of this protocol. Lúcás’s article on Yao’s Garbled Circuits and the Mina book with their reference links to papers served as valuable resources.
Now let’s get into it!
Yao’s Garbled Circuits is a 2 party MPC (2PC) method using only boolean gates. As the descriptor “MPC” suggests, Yao’s Garbled Circuits allow both parties to calculate a result without each party knowing the other’s private inputs. It works like this:
We split the two parties into the Garbler and the Evaluator. The two parties are semi-honest, meaning they will follow the protocol as outlined, but are still interested in knowing the other party’s input. While it doesn’t matter which party takes which role, the actions performed by each role is widely different. As a short introductory summary, the Garbler creates the circuit with garbled gates, and the evaluator uses said circuit to evaluate the final answer.
The Garbler takes the role of creating boolean garbled gates such as AND, OR, or XOR gates. The basis of a boolean gate lies in its 2 binary inputs and 1 binary output as illustrated below:
We’ll start with thinking about a simple case for a circuit: a single AND gate. An AND gate would have the 4 potential cases below:
How can the inputs of each party be hidden from each other?
The Garbler creates a label for each input and output case of as , respectively. Labels should not reveal the underlying value (0 or 1) of the input. Now, boolean gates will look like this:
Furthermore, a pair of and labels will be used to encrypt the outcome label of a given gate as shown below:
This encrypted gate is sent to the Evaluator, but the Evaluator also needs the and labels corresponding to the Garbler’s and the Evaluator’s inputs to decrypt a row.
Let’s assume that is the private input of the Garbler and is the private input of the Evaluator.
This case is very simple: just send it! The Garbler knows and since it made them, and since the labels should hide the input values, it’s safe to send one of the values as it is.
Now this case is a bit tricky. Since the Garbler should not know the Evaluator’s private input , the Garbler can’t simply ask the Evaluator for their input and send the corresponding label. Additionally, the Garbler shouldn’t send both labels to the Evaluator since the Evaluator could then decrypt two values in the gate. Thus, two constraints must be met to prevent exposed inputs: 1) the Garbler should not know what label the Evaluator picked and 2) the Evaluator should not know the other label. A process called Oblivious Transfer (OT) perfectly satisfies these conditions. (To understand how a simple implementation of 2-to-1 OT works, watch this video. Note that an error occurs at the end of the video, where should equal instead)
With OT, the corresponding labels can now be securely sent from the Garbler to the Evaluator.
Let’s look at the case where and for simplicity. As shown below, the Garbler will create the labels and the encrypted gate. Next, the Garbler will send the gate and . Additionally, they will send and through the oblivious transfer protocol such that the Evaluator only receives .
Finally, with and , the Evaluator tries decrypting all 4 rows of the gate. The Evaluator will successfully only decrypt the row to receive . As the final step, the Evaluator relays back to the Garbler, therein which the two communicate and the Garbler sends the corresponding value of the label back to the Evaluator, so both parties finally know the total result.
Now a couple additional questions will probably come to mind:
In the naive version of Yao’s Garbled Circuits, the Evaluator doesn’t specifically know which row in a gate to decrypt, but instead tries decrypting all 4 rows of a gate and settles on the one value that is decrypted properly. This insinuates that the Evaluator knows if they have decrypted a message properly. This can be done as per the method described in the Mina book which pads the original message with 0s. For example, say our original message b was padded with 4 zeros to be , and we encoded with like so: . If we then tried decrypting this encrypted message with a different key than , say , we would instead get something like instead of . Thus, we would be able to tell if the decryption succeeded or not by looking at whether or not the decryption result achieves the given amount of zero padding.
We can delegate each gate’s outcome label as an input label for the next gate. For example, if we had , we’d have the following encrypted gates:
Both our simple example of a single AND gate and the multiple gate instance above could expose the Evaluator’s input to the Garbler. For example, for a single AND gate, if the Garbler’s input was 1, and they received a result of 0 from the Evaluator, they can now tell that the Evaluator’s input value was 0. Now, how is this mitigated? The simple answer is it’s not explicitly addressed in the naive version of Yao’s Garbled Circuits with semi-honest parties, but is solved through optimizations done on top of Yao to protect against malicious parties.
Now what do I mean by this? Well, if the Garbler naively sends over gates every time with indexes and key orders like so…
…once the Evaluator successfully decrypts, say the row with index 2, they can immediately determine the two inputs are and . To prevent this leak from occurring, we rely on the process of garbling gates with the “point-and-permute” method mentioned later.
In this section, I’ll illustrate optimizations done onto the naive version of Yao’s garbled circuits, as outlined in the Mina Book. More specifically, we’ll go over “Point and Permute,” “Free-XOR,” “Row Reduction,” and “Half Gates.” Note that a full set of boolean gates can be created by using AND and XOR gates, which are the gates that these optimizations target.
The “pointer bits” in the given Yao article, are instead referred to as “Color bits” by Mina. Mina cites the BMR paper for this optimization, which does not name the bits themselves. Moving on, we’ll refer to these bits as “pointer bits” as well.
In a naive setting, the evaluator would need to try decrypting all 4 rows of an encrypted gate to obtain the gate outcome; however, a more ideal solution is to ensure the evaluator pinpoints and decrypts the one desired row in a gate every time. This can be done through “pointer bits.” This method also shuffles the circuit to prevent leaking the Garbler’s inputs to the Evaluator by way of gate row index.
A pointer bit is a random or bit paired with a given label. As in the Mina book, let’s set up the labels with pointer bits as such: with , with , with , and with . Next, the rows are ordered by the random pointer bits, effectively shuffling the encrypted gates.
Finally, when labels are tossed around from the Garbler to the Evaluator, the corresponding pointer bit must be passed around as well. With our previous example of and , the Garbler would send with a pointer bit and the Evaluator would receive with a pointer bit, telling the Evaluator to decrypt the first row.
Since the pointer bits are chosen completely at random, the Evaluator can no longer know which garbled row corresponds to which inputs. Additionally, from point-and-permute, the Evaluator only needs to decrypt one value per gate, instead of potentially trying all 4.
We can free the cost of XOR gates. Shocking, right?
For this, we need to change our input and output labels. First, the Garbler creates a random bit string . Next, we define , , where . This means that the superscript of labels that denote their true values can be removed such that the gates will change like so:
With the given constraints, the Evaluator can simply XOR the input labels to get the outcome label instead of relying on a Garbler’s gate with encrypted rows. This is shown below:
Since the XOR is done on labels, the Garbler does not have to send over the encrypted XOR gate thus, there is no risk of leaking values. Therefore, XOR gates become free, where the Garbler can just send labels with no encrypted gate and the Evaluator can determine the output label themselves.
Note that the change in labels doesn’t just affect XOR gates, but affects all gates within the circuit. This means, of course, AND Gates will still require an encrypted gate to be sent by the Garbler to the Evaluator as we can’t do the same magic for this different computation.
As a quick interlude on encryption to prep for the next section, I’ll explain a little about the actual encryption algorithm. Previously, I depicted an output gate value encrypted by two values through something like ; however, in the Mina book, they explain more specifically that the encryption algorithm is a hash function in addition to a one-time pad such that and . Now that we’ve shown this, let’s get into Row Reduction!
The concept of row reduction is fairly simple. Let’s first take our Free-XOR AND gate and apply our encryption algorithm to it.
With row reduction, we can remove the first encrypted row by setting it to “.” How can we do this? If we set , we can see that the first row becomes ! Of course, we have to uphold this equality across all rows now which will result in:
Now, you might be wondering how the outcome label of the first row case could be evaluated. Easy! It’s just the hash of the two given input labels.
In the end, the row reduction process reduces the gate overhead by one row. Additionally, the Evaluator can determine the output label of the first “hidden” row through hashing the input labels themselves.
Let’s now try to optimize AND gates with “Half Gates.” We’ll take a look at the 3 cases where only the Garbler knows one input (Case 1), only the Evaluator knows one input (Case 2), or neither knows the inputs of a gate (Case 3). The two halves of Case 1 and Case 2 will be merged to solve Case 3. We call back to the second gate in the figure “Encrypted gates for " as an example of Case 1 if is the Garbler’s private input and is the Evaluator’s private input.
Remember that with Free-XOR is the label for and is the label for .
Let’s dive into the two possible subcases of :
Subcase 1.
No matter what is, the gate output should be (). Additionally, we only need to encrypt with the label (). As such, we use the encryption if .
Subcase 2.
This subcase requires some more thought as different values of should result in different results. If , the result should be (), and if , the result should be (); however, similar to Subcase 1, we only need to encrypt with the label (). Therefore, we use the encryption if . In the case , we use and in the case , we use , fulfilling our desire of having two different outputs for the two different cases of our known input .
In total, the two rows in this AND gate will be and . But hold on… Remember row reduction? By additionally applying row reduction to our two rows, we can get one final ciphertext!
Let’s dive into the two possible subcases of :
Subcase 1.
If , the result will always be (). This is simple enough for the Garbler to create with the Evaluator’s label () as the encryption key: .
Subcase 2.
Once again, the latter subcase, , becomes complicated due to the possible varying outcomes dependent on . So how can this subcase be resolved? We’ll use the Evaluation’s label () as the encryption key again and create . Let’s take a look at how this can be used to create both outcomes:
First, the Evaluator decrypts the ciphertext to obtain . Next, the Evaluator XORs this value with the pertaining label. That is, if (), the Evaluator computes the outcome label for , exactly how we want it! On the other hand, if (), the Evaluator computes the outcome label for 1. Thus, we have successfully created a ciphertext for that can be used to generate our desired outcome labels.
In total, we get and for this AND gate. Just like in Case 1, we can also apply row reduction to reduce this to one ciphertext row!
To optimize this case, we’ll employ a little trick:
If the is a random bit chosen by the Garbler, this means that the AND gate can be optimized via Case 1, since the Garbler knows . Furthermore, if the Garbler can leak to the Evaluator, the AND gate can the optimized via Case 2, since the Evaluator will know an input. Finally, all together, the XOR gate between and would be free from the Free-XOR optimization. Therefore, in total, an AND gate where neither input is known by the Garbler or Evaluator can be reduced down to AND gate AND gate 2 ciphertexts!
Now, this is banking on the fact that the Garbler can leak to the Evaluator, but how can this be done? First of all, is safe to leak as the Evaluator would not know the random value and therefore would not be able to discern the private input . So how’s it done? By setting as the pointer bit corresponding to the given value!
Since the random ensures the pointer bit stays random, the Evaluator shouldn’t be able to discern the value of from the label or the pointer bit.
Thus, we finally have our final structure for an AND gate where neither the Garbler or Evaluator knows the inputs. Below, we try to show this scheme with a diagram and additionally include an example of how it would run with the values , , and .
Therefore, Case 3 can be implemented through Case 1 and Case 2, costing it only two rows.
In the end, I showed how Yao’s Garbled Circuits runs as an MPC protocol and introduced a couple optimizations that can be added on top of Yao’s Garbled Circuits to drastically reduce the communication overhead between the Garbler and Evaluator by reducing the number of gate rows. The total results of these optimizations are shown below:
Written by Ashley Jeong from A41
