 Hi, I'm Rahul Rajshuri, and today I will be talking about improved primitives for MPC over mixed circuits. This is joint work with Daniel, Satyajit, Marcel and Peter. Before we begin, we need to define what MPC is. It's a class of protocols that allows a bunch of mutually distrusting parties to come together and evaluate a publicly known function such that the inputs or anything about them is not revealed. MPC comes in different flavors. The first categorization of MPC is based on the corruption setting. Honest majority, where the number of parties are less than half, and dishonest majority, where more than half of them can be corrupt. Based on the threat model, we have two categories, semi-honest and malicious. Semi-honest is when the adversary follows the steps of a protocol, whereas a malicious adversary might deviate from the steps. In this talk, I will be focusing on the challenging setting of dishonest majority with active security, although I would like to mention that our techniques are general and apply to other settings as well. Additionally, we are in the pre-processing model where computation-heavy function-independent stuff is computed in the offline phase. Most of this talk is going to be an effort to propose a better pre-processing phase that makes for a fast online phase. These are our contributions at a high level. We introduce a new cryptographic object called Etabits. Etabits allow us to switch between arithmetic and binary worlds efficiently. Using Etabits, non-linear operations such as truncation and secure comparison become faster than previous works. Etabits can be used across all corruption thresholds, although we observe the most gain in the dishonest majority setting. We also propose a normal current use protocol to generate Etabits. The protocol exploits temporary resilience properties of binary circuits and might be of independent interest. Etabits are up to 25 times faster in communication and up to 47 times faster in throughput as compared to previous state-of-the-art. We have also benchmarked applications such as biometric matching and CNNs, which I will show at the end of the talk. In MPC, we have different computation domains like arithmetic where the shares are over mod p or mod 2 to the k and the binary world where the shares are over mod 2. Due to how these worlds operate, each domain does well for certain operations and not so well for the others. Due to this, there is motivation for efficient ways to switch from one domain to the other and back. For instance, when we consider applications such as machine learning and biometric matching, we need a lot of conversions. Works such as ABY and ABY3 have made a lot of progress in this direction by proposing fast ways to switch back and forth. But most of these works operate in the weaker, honest majority setting. Only recently, works such as the Dabits paper have proposed a framework for the dishonest majority setting with active security using speech shares. We further this domain by proposing a fast framework for switching between arithmetic and binary worlds for all the settings. Before going into our protocol, let's take a look at the related work. The work of RW19 proposed an efficient way to create an object called a Dabit which is a doubly authenticated random bit sharing. A Dabit is a bit X that is shared among all the parties over ZM and F2 along with an information theoretic MAC such as speech. Alpha is the key that is additively shared among all the parties and gamma X of i is the MAC that is also additively shared. For the rest of the talk, I will ignore the corresponding computation on MACs for simplicity. These are some of the highlights of Dabits. Dabits are used to switch between arithmetic and binary domains and there's a lot of different ways to efficiently generate them. RW19 uses a cutting choose based approach to batch produce Dabits whereas follow up works use a more efficient random linear combination based approach. The bottleneck in efficient generation is that we need to do a multiplication of a random secret value over ZM per Dabit. Due to this, the cost of creating a Dabit comes close to the cost of doing a comparison over ZM. Taking inspiration from Dabits, we propose extended Dabits called E-Dabits. Instead of one bit being shared in both the domains and E-Dabit is M random bits shared in F2 and the corresponding value shared in ZM where M is either a prime order field or a ring. Similar to Dabits, E-Dabits can be used to convert between arithmetic and binary domains. They can be used for any correction setting but we observe the most gain for the dishonest majority setting. We also propose an efficient way to create E-Dabits. The key difference between generation of E-Dabits and E-Dabits is that we replace the multiplications of ZM in Dabit generation with multiplications over F2 for E-Dabits. As a result, communication is between 2 and 170 times better than when using a purely arithmetic approach and between 2 and 60 times better than using Dabits. At a high level, this is how we generate E-Dabits across different security models. In the semi-honest case, it's pretty straightforward how we generate them. We can let each party secret share a set of E-Dabits which I will refer to as private E-Dabits because one of the parties knows the underlying value for each of these E-Dabits. Taking one private E-Dabit from each party and putting them through an added circuit gives us what we call global E-Dabits. Global because none of the parties know the underlying value. For the active security case, we let each party PI secret share a bunch of E-Dabits with max. We then proceed to verify this set of E-Dabits proposed using a modified current choose protocol and at this point we will have verified private E-Dabits which we can put through a binary adder to get verified global E-Dabits. Before going into the new current choose protocol, let's recap the original current choose for multiplication triples over a field. First, the parties propose a bunch of secret share multiplication triples which are then shuffled and C of them are opened and checked for correctness. If all of them are consistent, the remaining triples are put in buckets of size B. Within each bucket, the top triple is selected and a pairwise checking procedure is carried out with every other triple in the bucket. If all the checks pass, the top triple is output from each bucket. We want to do a similar thing for E-Dabits but there is an important difference to take care of. Checking two multiplication triples requires no additional information. In other words, it's a self-contained check whereas with E-Dabits, the relationship is non-linear so we need authenticated triples. In this case, we use tinyOT to generate them. The new approach would be to let the parties generate random secret share tinyOT triples, run a current choose protocol to verify them, and once we have secure tinyOT triples, we can use them for current choose with E-Dabits. Our approach instead was to let the party that is proposing the set of private E-Dabits also propose the required tinyOT triples. We then proceed to use these unreliable triples in the current choose with E-Dabits directory. Turns out, letting the adversary propose potentially incorrect triples doesn't actually increase the chances of winning in the current choose game. It did, however, mean that we had to reanalyze the game and prove that the adversary doesn't gain any additional advantage, which is what a large part of the paper does. In fact, we found that this makes it a bit harder for the adversary to cheat. This is a modified current choose game at a high level from the perspective of one of the parties. Party Pi secret shares a bunch of E-Dabits and the required tinyOT triples. We then shuffle them using two publicly sampled permutations. We open C E-Dabits and C prime tinyOT triples and verify the consistency. If any of them are inconsistent, we abort. The remaining E-Dabits are placed into buckets of size B, and triples are placed into buckets of size B-1 times M. As there are B-1 pairs of checks within each bucket, and within each bucket, similar to the original game, we select the top E-Dabit and perform a pairwise check with the other B-1 E-Dabits using M-tinyOT triples per check. Once again, if all the checks pass, we output the top E-Dabit to get verified private E-Dabits. So we know how to do the shuffling, we know how to do the bucketing, we also know how to go from verified private E-Dabits at the end to verified global E-Dabits. What we have not analyzed so far is the bucket check protocol. First, let's consider the simplest possible case, which is verifying just two E-Dabits. We verify them by computing the sum over F2 and ZM and opening it. Computing the sum over ZM is local and for the binary case, we need an adder circuit. The guarantee we have is that if at least one of the E-Dabits is good and the triples are good, then cheating will get caught. We need a set of triples for the adder circuit, which we'll get into later. These are the different cases that can occur in the bucket check. X and Y are E-Dabits used in the check, with X being the top E-Dabit and TRIPS being the set of triples that we need. In case 1, good E-Dabits are ratified in the bucket using a bad set of triples. For simplicity, we assume that only one of the triples was corrupted. In this case, the check will not pass because at position I where the triple was corrupted, the corrupted triple will flip the output of the carry computation, making it inconsistent with the value over ZM, so the check fails. In case 2, we have the top E-Dabit being bad and the triple that is used for the check also being bad. For simplicity, we assume that the corruption pattern for the E-Dabit and the trip is the same. So the error in the E-Dabit is going to be cancelled out by the error in trips, resulting in the check passing. Case 3 is similar, with errors being cancelled out and the adversary going undetected. Cases 4 and 5 are special because when both E-Dabits and the check are corrupted, the adversary may or may not need a bad trip to pass the check. Which of these two cases is possible is determined by the type of adder circuit we use. For some circuits, however, it may be the case that the adversary can pass in both the instances. And this is something we want to avoid because it gives the adversary too much power to cheat. Now technically, the adversary wins in case 3 because it was able to fool us by using bad data. However, for our analysis and for our protocols, we do not consider case 3 to be a win for the adversary because the E-Dabit that is finally output from the pocket is a good one. There is nothing the adversary gains in the situation because the goal is to be able to produce incorrect verified private E-Dabits, which cannot happen from case 3. Going a little deeper, this is the exact adder circuit we use. A standard ripple carry adder circuit which computes the carry as shown. To compute m-carry bits, we need a total of m-tinyo-t triples. So the cost to add two E-Dabits of length m is m-triples. Before we analyze the probability that the adversary wins in bucket check, we describe another property we require from the circuit, which restricts the power of the adversary significantly, making the analysis a lot easier. The property is called weakly additive sample recipients. Since we are using unreliable triples, we need to be careful about where and how we use them in the circuit. More concretely, we want to restrict the freedom of the adversary in terms of how it passes the check. The adversary should not be able to use a bad set of tinyo-t triples, regardless of how they are corrupted, to pass the check in the following two cases. Case one, where we have two good E-Dabits, and case two, where the top E-Dabit is bad, along with the bad trip. Luckily, the standard ripple carry adder circuit has this property, so we do not need any fancy circuits. Before we go into the intuition for calculating probabilities, let's abstract away E-Dabits and triples. The real world protocol is very hard to analyze, because to do the full analysis, we also have to consider the number of different ways in which an E-Dabit of length n can be corrupted, which is 2 to Tm. We need to do the same for tinyo-t triples, as well as look at the possible types of pairings between the corrupted E-Dabits and corrupted triples. Instead, we abstract E-Dabits and triples away, replacing them with balls and triangles, while giving the adversary a better chance at winning the game. A ball is one E-Dabit of length m, and a triangle is the required number of tinyo-t triples for the check. In this case, m. We assume that the error in a corrupted ball is always cancelled out by the error in a corrupted triangle or a ball. In the paper, we show that security against adversaries in the ball and triangle game implies security in the actual protocol. So, to recap, this is what a bucket of size 3 would look like. It has three balls and needs two triangles for the check. We reject if any of the following configurations of balls and triangles occur. The probability of the adversary winning the game is the probability that the adversary goes undetected when we open C-balls and C-prime triangles, multiplied with the probability that the adversary passes the bucket check protocol. We can imagine bucket check as a game between the adversary and a challenger. Assume that there are three buckets, each of size 3. The adversary first picks a bunch of balls, corrupts them however it wants and how many it wants, and sends them over to the challenger. The challenger shuffles them and opens C-balls. If they are inconsistent, it sends the permutation of balls to the adversary. The adversary then chooses the number of triangles to corrupt based on the permutation it received and sends them to the challenger. The challenger repeats the same process of opening and verification. The challenger runs bucket check on the remaining set of balls and triangles and it sends 1 or 0 depending on whether the checks are passed. The adversary wins if it receives a 1. To see how the probability is calculated, assume the arrangement of balls after the challenger shuffles them is as follows. Based on this, the only possible arrangement of triangles favourable to the adversary is the following. So the probability of bucket check comes down to the probability of triangles hitting this one permutation. Since we analyse this for one configuration of balls, for the total probability we need to sum over all possible configurations of a set of balls. That was some intuition about the analysis. And these are the parameters we got from analysing it. Most notably, for 40-bit statistical security, it is enough to open just 3 eBits and 3 sets of trinearity triples with a bucket size of 3. This is analogous to the previous cut and choose game with multiplication triples, where you have to open a minimum of 3 triples for security. Since not all applications need eBits in the order of a million, we also calculated what it would take if we wanted to generate just a few thousand eBits. For 40-bit security, all you have to do is increase the bucket size to 5. Using eBits, we have adapted protocols for truncation and secure comparison from previous works and made them faster with eBits. We have made sure that our constructions work over signed and unsigned integers. All settings considered together, our communication improves by a factor between 2 and 60 over eBits. In throughput, our improvements go up to 47 times. We have also given benchmarks for various applications like biometric matching, logistic regression, convolutional neural networks across different settings. The code for benchmarks is available as a part of the MP speeds library. These are some of the benchmarks that showcase how eBits performed against a fully arithmetic approach based on speeds and against eBits. For comparisons, we are between 3-5 times faster than eBits in the dishonest majority case with active security. Looking at the communication, we are about 5 times faster than eBits in the dishonest majority case and in the honest majority case. In the end-to-end applications such as mobile net, eBits is faster than dek19 when comparing run times by about a factor 3 in the dishonest majority case and as fast as them in the honest majority case. In terms of communication, eBits is as efficient and in some cases more efficient than dek19. So that was eBits and thank you for your attention. These are the references used in the slides.