 Thank you for watching this video, I'm Wu Chenghai from Northwestern University, and in this video, I'll talk about our paper, Better concrete security for half-gauge garbling in the multi-incidence setting. This is a joint work with Professor Squashen, Johnston Katz, Wang Xiaowan and Yu Yu. First, please let me review Yaskarbo circuits. The Yaskarbo circuit is a two-body computation protocol. It allows two parties to jointly compute functions without revealing anything beyond the output of that function. The Yaskarbo circuit represents a function as a Boolean circuit with AND gates and XOR gates, and encrypts the computation gate by gate to maintain the privacy. Over the years, there are many optimizations for the garbo circuits, including point-and-permute free XOR and garbo-zero reduction. Another important optimization is the half-gauge. It is the state-of-the-art garbling scheme. As we know, the garbo circuit has a huge burden on the network communication. Before the half-gauge, the free XOR technique has made the computation of the XOR gate free, and the half-gauge reduces the network communication on the computation of the AND gates. It is also compatible with all these optimizations. Another important optimization is the fixed-key AES-based garbling. It was first appeared in the Yaskarbo scheme. It makes full use of the hardware support to instantiate the hash function in the garbo circuit using the fixed-key AES, so it reduces the overhead of the computation. We pay attention to these two optimizations because we find that when the hash function in the half-gauge is instantiated with the fixed-key AES, there could be a compromise of security. In this paper, we gave a systematic study on the concrete security of the half-gauge. First, I will show an attack on the current half-gauge implementations. Then I will point out where the deficiencies are, and it is directly caused by the inappropriate instantiation of the hash function based on the fixed-key AES. And also, there is a lack of concrete security on the previous papers, and mostly they just focus on the asymptotic security bond, and that's also the reason that people ignore this attack. At last, I will give a new abstraction and construction of our hash function. It is called the multi-instance tickable circular correlation robust hash function. I will provide a new and better concrete security bond, and at last I will show our implementations and its performance. The weakness of the half-gauge implementation mainly lies on the fixed-key AES based hash function. In our attacks, the attackers succeed in running time proportional to the 2 to the k over C. Here, the k is the b-length of the gavel label, and the c is the number of the AND gates in the circuit. If the circuit generator gavels the circuit with 80-bit label, and the number of AND gates in the circuit is 2 to the 40, then this circuit can be completely broken. And the attack in time would be within several days, and if we run the attack in the cloud, it would just cost several dollars. And the circuit with the b-length of the label, 128, and the number of AND gates 2 to the 40 has only more than 80-bit security left. And we actually implemented our attack, and the result of the attack is consistent with our analysis. And also, this attack can be extended to multi-instance case. It means that when the adversary receives more circuits, it can apply this attack on all of them, and there will be a higher chance for the adversary to break one of the circuits. Before we step into the details of the attack, let me introduce the half gate protocol. In the half gate protocol, there are two parties, one is the circuit generator and another is the circuit evaluator. When gaveling and AND gates, the circuit generator will prepare the labels for each wire. For example, in this wire, WA0 is the zero label, and WA0xOR is the one label. And this R is the global delta. It's a correlation between two labels, and it makes it compatible with the FriggaxOR technique. Then the circuit generator will construct a gavel table consisting of TG and TE, and then sends the gavel table to the circuit evaluator. And the circuit evaluator at this time has two labels for the input wire. It will use these two labels and the gavel table to compute the output label of this output wire. And here we need to pay attention to these two elements. One is the TG in the gavel table. It's a linear combination of the hash of the zero label and one label, and another is WA label in the input wire. Here is the details of the attack. After the evaluator receives the TG in the gavel table, it can compute WA which equals to TGxOR, the hash of WA and J. This J is a gate identifier. It's just a number indicating which gate it is. And it equals to this. And PB is just a random bit. So there is one half chance that PB will equal to zero. In this situation, this term is canceled and the HA equals to the hash of WA, XOR and J. To look into more details, we need to know how this hash is implemented currently. It's a little bit like the MMO compression function, except this pi now is a fixed key block cipher. It means that it has a fixed and a public key. And K is the combination of input X and the gate identifier J. So in detail, this HA equals to distance. And here, the evaluator knows WA label. It knows circuit identifier and it knows this block cipher. The only thing that the evaluator doesn't know is R. So if it happens to know a W star, where the hash of W star, which according to the implementation of this hash function equals to this HA, then it can reverse this term and guess R. R is the thing that keeps the privacy of this circuit. If the circuit evaluator knows R, then it can break the whole circuit. So for each AND gate, the evaluator knows one of these pairs. Then for the whole circuit, the evaluator can collect all these pairs and make it into a table. And here is how the attack goes. When the evaluator is controlled by an adversary, the adversary will randomly generate a W star. Then it puts this in this hash oracle. And the oracle gives an output of this H star. Then it will check if this H star happens to equal to one of the HA here. If it does, there is a chance that it can reverse the term we just seen and guess R, then it just breaks the whole circuit. And we actually implemented this attack. Here is the result of our implementation. From the level figure, we can see that when we collect more number of AND gates, it would take the adversary less queries to the oracle. It means that it takes the adversary less time to break this circuit. And it means that the larger the circuit is, it is easier the adversary will break this circuit. And at the right side, it is we tried to break the circuit of different belays of the labels. We tried at most for a large circuit, which has the labels of 64-bit. And it just takes a couple of hours to break it. If we interpolate this line and when the size of the labels is 80, we predict that it will take just 200 and 7 machine months to break this circuit. And if we run it in the Google Cloud, it will just take around $3,500. And because this attack is highly parallel, if we set out more machines, for example, 267 machines, we can break a circuit in a month. After knowing what this attack is like, it's time to think about how to fix this problem. The first problem comes from the fixed key AES. Because the key is fixed and public, the adversary can continuously carry the oracle. Do the brute force attack and guess the pre-image of the hash values. The second problem comes from the lack of the concrete security bond. The asymptotic security bond is not solid because the circuit size can be very large. And the first step we need to do to get a better concrete security bond is to design a new abstraction for the half gate protocol. And which can guarantee the concrete security of the half gate protocol. The next step is to design a new hash function which can satisfy all the security requirements from the abstraction. This is abstraction designed for the new half gate governing scheme. It's called multi-instance tricable circular correlation robust hash function. It takes three inputs. The first W refers to the input label. The second I refers to the gate identifier and now we call it a tweak. The B refers to that random bit. And clearly it models the use of the hash function in the governing scheme. And the output is a hash of WX or global delta R with tweak I and a linear combination of the global delta. And the security definition of this hash function requires that this hash function should be indistinguishable from the random functions. And there are two additional requirements for this hash function. First that we assume the attacker is given new instances because our attack applies to the multi-instance setting. So we take it into consideration. And another requirement is that the queries of this form should be called for at most mu times. And it also means that this tweak can be used for at most mu times. This is the hash function that we designed in the sense of the abstraction. It's called MMOE and it has two inputs. The first input X is the input message. The second input I is the tweak. Here the sigma X is the linear automorphism. It has two properties. It is linear if sigma X X or Y equals to sigma X X or sigma Y. It is automorphism if sigma X itself is the permutation. And at the same time sigma X X or X is also a permutation. There are many ways to realize the linear automorphism and we choose one that is simple and friendly to the hardware support. Here the E is modeled as an ideal cipher. The key is this tweak I. It means that every time we change this tweak I we have to do a key scheduling for this E which is ideal cipher. It's different from the previous insecure implementation where they use fixed key AES as the random permutation and they just have to do the key scheduling one time before the gobbling. After the design of the hash function we embed the hash function back to our abstraction and derive a new concrete security bound. Here the mu is the maximum time that a tweak I can be reused. P is the number of queries the adversary can make to the ideal cipher E. Q is the number of queries that the adversary made to other oracles. This row is the entropy of this global delta R. This security bound can guarantee the concrete security for the single instance case. But when we consider the multi-instance case actually this mu can contain a little uncertainty because when the garbler garbles the circuits it can garble different circuits. It can reuse this tweak for multiple times so this mu can be as large as this Q. So how do we fix this problem? There is an easy way to do this. Instead of starting this gate identifier i from one we can start it from a random point. Every time when the circuit generator generates a new circuit it generates a random point and starts this tweak from the random point and then there is a low chance that this tweak will be reused and this can be proved using the boss and beans game. Putting all these efforts together we can derive our ultimate concrete security bound. Here the mu is times that a tweak can be reused. It has been bounded by starting the tweak from a random point and P is the number of queries to the hash oracles and C is the total number of AND gates in the circuit and K is the bit less of the labels and L is 128 because we instantiate our hash function using the AS 128 and now even regarding to the practice this bound can be negligible. From that bound we can get two important instructions for our implementation. If we guard both circuits with 80 bit labels and the total number of AND gate is less than 2 to the fourth 3 then we can get 78 bit of computational security. If we guard both circuits using the 128 bit label and the total number of AND gate is less than 2 to the 61 we can get 125 bit of computational security. At last I will introduce our implementation and performance as a reminder this is how we construct our hash function. This is a super random permutation so we implemented using the AS 128 with AS9 instructions and this sigma x is a linear sum of them and we implemented using the SSE instructions from Intel and because it's a keyed random permutation so we have to do the key scheduling every time before we call it and it will cost some time so we find that Gron has efficient implementational batch key scheduling in their CCS15 paper and using their muscle we can batch eight key expansion together and maximize the efficiency. This table shows the original half gate performance and our new protocols performance and you can see from the security side we enhanced the security from the 89 bits from to the 125 bit when we used 128 bit label and for the efficiency when the network manualizes limited the performance are the same because in this situation the network is the mean bottleneck and when there's enough network resource our implementation is just 35% slower than theirs and after this paper is published we further optimize it now these numbers are 20 so in summary we enhanced the security but made little compromise on the efficiency and all of this code has been published in the EMP toolkit and this is a link to the codes and also there's a link to our full version of the paper and that's the full content of this video, thank you