 The second talk. The second talk in this session is Locals Concentrant MVC, Combining DMR, and Obvious Transport by Kamheiji, Peter Shior, and you are also showing your access and your own role as a speaker. Thank you. So yeah, this is James Worm with a colleague from Miami University, Peter, who is also in the room. Yeah. So first I'm going to introduce voice MVC because maybe most of the people in the room are more interested in the Obvious Run stuff. So I will go smoothly from JAL Scramble Circuits to DMR, which is a multi-party version of JAL. And then I will speak about the results in our paper. First, we have a transformation from any MVC protocol or binary circuits to DMR Bravo Circuits, so we will continue in France. Then we realize also about some robustness property of this carving in DMR, and finally we have an instantiation of this compiler using the MVC. So multi-party computation, the classical example, is that you have this set of parties, they are millionaires, so who is the richest? So if we have some trusted party, this problem would be solved very easily because the parties just have to tell this trust person how much money they have, then when the trusted party has all of this, she can compute, though Alice is the richest here, she has built everybody. So here there are no problems at all, even if you have music-having parties because they are just outsourcing all this computation to the trusted party. But now the real world is sometimes not so nice, so when we don't have this trusted party we have some interactive algorithm, this is our MVC protocol, and now the problems we face is that, yeah, we have these malicious parties taking part in the MVC protocol, and they might not follow what you want them to. And the way we want to capture security is by saying that this is indistinguishable from the first case. So there are so many flavors of multi-party computation and this talk we will focus on Boolean circuits. We will also work on this offline online setting or pre-processing online setting, because the parties can use some correct randomness independent of inputs, you put all the heavy work there and once you have that you have a very efficient online phase. The adversarial is static which means that it's going to corrupt the parties at the beginning of the protocol, malicious which means that they can deviate however they want, and we assume also that it's always majority. Yeah, in this setting what we want to do is bounce and we want concrete efficiency. So if we start with the classic construction of Giao for two-party computation you have found some bof they have some inputs 1, 2 and they want to compute some circuit C on them. So Alice would gargle this circuit C this some encryption of the circuit which is going to send to bof then both parties are going to engage in this input encoding protocol both bits encoded inputs and with that he can evaluate the circuit and then just send back the result to Alice. So this is in the SEMS case and here what happens is that from these encoded inputs and the circuit both cannot learn about the inputs of Alice. Alice doesn't know anything about both inputs apart from the result of the computation. Now in BMR things are pretty similar the parties also are going to gargle some circuit together that they are going to encode their respective inputs private inputs and once they have this they can locally evaluate this gargle circuit that they have produced. Now we also have some problems if we compare with Giao. So in Giao we have just one party doing the gargle but this is not the case here we cannot trust any single party we are in this situation with this setting and we need to do these steps of gargling and encoding using an experimental MPC protocol and the good thing though is that we can gargle all of the gates in parallel so this is how we are going to get constant gargle. So that is the hardest step out of this gargle and input encoding the hard bit is how to gargle the gates and this is what we are going to focus on for the rest of the talk for the next minutes So these are the costs of gargling a single gate in BMR since it was proposed in 1990 so the first proposal was required a lot of zero edge proofs for some some random generators this then was a bit overlooked until 2015 when Lidl did the gargling using the speech protocol which required a linear number of modifications to gargle every gate then the year after in PCC with Lidl and SMART we have our paper doing the gargling using somewhat of an encryption we still have some overhead due to some zero edge proofs that we did for the ciphertext, so this was a quadratic overhead that is presently produced works now in this talk we just need to do a single modification in the underlying technical to gargle a gate we rely on the obvious transfer the external MPC protocol and we also achieve the VXR property I should say concurrent work by one runner-looting and cats presented in CCS is here they achieve similar results so starting smoothly how to gargle a gate with Lidl you have your truth table you have input wires U and V the parties are going to pick two random keys each wire then the encrypted truth table and permute the entries in BMR it is very similar the difference now is that basically we have n called keys of everything so instead of having two keys per wire we have two keys per party per wire we are going to do the same encrypted truth table but now instead of encrypting a single key we are encrypting n keys and we use n keys two n keys and each party knows a perfect keys for everyone once we have encryption we do the permutation so the encryption in BMR we are scared about if you want to encrypt one of the keys it is quite easy imagine you want to encrypt one of these entries so you want to encrypt one of the keys so if you want to encrypt the key for party J you are just going to mask it with this random value that you think with F and once you have encrypted one of the keys you have to encrypt the other so it is the same thing at times the good thing is that these PRFs can be computed outside of MPC world and then this becomes just a local operation you just have to do something, sorry so this is how you encrypt one of the entries and one thing to note about this is that this encryption is manipulative so if you look at it if you have the encryption of x here and you add some value y to it you get the encryption of x plus y and this is something that we are going to use for the traveling of a gate once you have your encryption of this key for value 0 we are going to add this product on the right so if you look at it you have some these are some bits on the right some secret permutation bits and you have those multiplied with some offset rj so this offset rj is what allows to have the freq sort property we define the keys for value 1 which would be the key for value 0 plus this offset and because of this that we showed before here we are going to get either the encryption of the key for value 0 if the bits on the right are 0 or the key for value 1 if that is set to 1 so how to grab a line of gates the parties are going to do some coin tossing to get these secret permutation bits once they have that they are going to compute the shares of the product that we are missing so these are bit bit products or bit stream products and once they have that and the encryption of the entries they can produce the garball gate and they can do this in parallel so bit more graphically the parties are going to use some multiplication in the Lightning BC protocol and then to do the bits in products they are going to use a correlated utility which is very efficient things there is some caveat here that we need to check consistency between these two smaller protocols so we need to make sure that the lambda values input to the correlated utility correspond to the ones but this is very efficient this is just some random combination of values and you can take the equals so yeah this is the first result this is transformation you get your favorite MPC protocol in F2 and now you can get constant problems by doing this the second result when we start proving this protocol we realize that BMR is actually quite robust and I am going to explain what I mean with robust now so the idea is that as we have all these copies of the keys of each party in the garbled circuit now if the adversary gives some input values in the circuit to a party and a party garbled the circuit send them to the adversary now we can let the adversary modify the circuit in any way he wants this in particular this modification we can capture as an additive error and now when the parties are going to evaluate the circuit they are either going to get the actual value or everything is going to result in an abort that also doesn't really get information about inputs so we are well safe and why is this the case well again if you think about this malleable encryption scheme that we had this error that the adversary can introduce can only change the output if it manages to switch the key so if I am going to party I am party jerry in order to cheat me you would have to guess my offset rj I already know it so this becomes negligible as long as R is long enough in previous works it was allowed to introduce these kind of errors in the gardening but not after seeing the carbon circuit also the reductions to the security the PRF were not very tight the whole circuit was required to be authenticated whereas in our case we just need to authenticate the smaller products third result we have is an instantiation of this gardening using 1080 so 1080 is a protocol a multi-party protocol for wind and circuits it was described in 2015 and it was also optimized recently in the concurrent work by one at all and the only thing you need to know about this is that in order to achieve marisi security they use this information ferretic max that looks like this so in order to authenticate the value x there is some key that has some values k and r where r is some global value and now we use this global value r of 1080 to be the offset that is required for Fritz we are basically solving two problems at the same time we get the active security of 1080 and the offset for Fritz we look at what we have before this is what we have for any MBC protocol for binary circuits now if we use 1080 we can basically drop all of these because we have it all right in between those people so basically one multiplication in 1080 is one global gain in the R going to the efficiency this is how it has evolved over the past years so speed CMR was something in 2015 and here when we say mascot BMR this hasn't been an actual work but you could think of doing the same thing as speed CMR but using the recent protocol of mascot which is like a more efficient part of speeds so the improvement of over the previous works was small but there was some improvement whereas now we are going basically from gigabytes to megabytes so this is the communication cost for covering the AS circuit and we have for free parties we need 15 megabytes for 10 with 67 and if you look at the most efficient wonder they would require almost 4 gigabytes for free parties or 55 for them in conclusion we have constant rounds for your favorite MVC protocol for current circuits also free the only overhead that you have is this correlated OTs so if you have a security parameter overhead if you are willing to use 1080 to get more efficiency it gets even better we have also improved the understanding of the security to the MR now we have this unauthenticated circuit that gives us a slightly better online phase and we can think of different open problems so can we further optimize the garb of the MR so as I said we have 10 copies of its key on a garbable entry so can we further reduce it because then it skates 4 times the number of parties in the parameter and also we have to build a quadratic number of PRF valuations to garbable which is not very bad for the ESNI on hardware but still doesn't do it maybe we would like to optimize how about tanyoti can we optimize tanyoti and then just wrap the improvement here or can we think of any other MVC protocol that for example exploits the parallelism we have on garbable MR can we design some efficient activity security protocol to do this that's it on my side I will take any questions thank you we have plenty thanks see you again