 Thank you So I'd like to start with a quick introduction to secure to party computation So the idea is we have Alice and Bob and they have some circuit C they want to evaluate on input sex and Y and So the goal is for us to develop some protocols that let's Alice and Bob learn some value set and The properties that we want is that the protocol is correct So the value that I was involved learn is actually the output of the circuit Second we also want some kind of privacy so that the private inputs are kept private even after the When we talk of active security we say that this should hold even if we have an adversary that can corrupt one of these parties and deviate from the protocol in any arbitrary way For this work in particular we also care about a somewhat more vague property We want the protocol to be practical and what this means is basically we want it to run in some reasonable amount of time For reasonable sizes of circuits, and we want it to be practical enough to solve Kind of real problems. This leads us to the first motivation for this work So we actually want to use this to solve some real problems So one thing that we've been very interested in in office is Computing the outcome of auctions. So I think we always have to mention this Thing here a few years ago when some people in office actually implemented the and secure auction for some sugar beet farmers in In Denmark, so there are real people who care about these The kind of more specific motivation for this work was that when we at least started this there was kind of a lack of diversity of practical Solutions to this problem. In fact, all the solutions that we saw were a based on yaw's gobbled circuit technique and not that there's anything wrong with this approach, but You know just for having a larger pool of ideas to draw on it seemed interesting to see can we do something else? So what are the main building blocks of our approach? So instead of using yaw? circuits we At kind of the base of our approach is another passively secure two-party computation protocol, namely the GMW protocol and Then on top of that we add some information to your information theoretic max to sort of ensure that active adversaries behave Honestly now this approach on its own would not necessarily be Practical Because the GMW protocol uses a lot of OT and we know OT must be based on public key photography, which is Usually seen as something computationally expensive so to get Efficiency what we use is these OT extension techniques where we can take a small seed of oblivious transfers that are Let implemented with some public key photography or something that and then we can expand it or extend it to this huge amount of OTs that are amortized a low amortized cost and particularly for our Protocol we're going to rely on the passively secure protocol of Isha Adele and then we're going to add some tricks to make it So our results are that we get a new OT extension technique with active security Now this technique does not improve what we know we can do sort of asymptotically, but it gives us a more practical protocol Which is only affected to slower than this passive secure protocol of Isha Adele What this translates into is that we can implement this in Java and we can get something like half a million OTs per second per core and Using this we get our practically Practical 2pc protocol which is uc secure against an active static adversary in the random Oracle model In terms of practicality we get something like 20,000 gates per second or If we just look at the online phase we can actually do More like a million gates per second Okay, so what did this mean? Well at least when we did in this implementation We had the fastest implementation of 2pc That we knew of unfortunately for us within kind of the recent year Khojda, Shilat and Shen they presented a new Implementation based on garbled circuits, which does a little bit faster than we do Well at least it seems to show that our approach is somehow competitive With the garbled circuit approaches and anyway, it's kind of hard to compare because everything is implemented on different hardware and so on anyway let's start with a Kind of high-level overview of our protocol. So As I said, we are based on the gmw protocol. And so let's see how this works Alice and Bob. Let's say let's think of everything here as just being bits So what Alice and Bob will start by doing is that they will create XOR sharings of the input bits then they'll proceed in a gate by gate fashion and If this for instance is an internal gate of the circuit What Alice and Bob will do is that they'll evaluate this gate in a way so that they learn an XOR sharing of the gate And now if they do this for all gates in the circuit they will end up with an XOR sharing of the output gate and Then it's very simple to learn the output. You just exchange shares and reconstruct Okay Now this is very good for the passive case, but there are some kind of obvious problems in the active secure case namely Maybe the most obvious thing here would be that Bob could just send some different share of the output and this would disrupt the correctness of the protocol So In order to deal with this what we do is just add messages indication codes to all these XOR sharings throughout the whole That you know are in the whole protocol and the idea is then we can use these These mechs to ensure that the opposing party will use the correct shares that they're supposed to Okay, so at a very high level. This is kind of all of all the So like the two previous talks we Live in this pre-processing model and what we do in our pre-processing model is Essentially just we prepare a lot of authenticated Random messages so bits with the max on them Particularly we need one for each input gate and we are going to need 16 b for each and gate to get security 2 to the minus b times size Log the size of the circuit this means that for very large circuits with this b Parameter is going to be low. So we're going to it's going to be something less than 10, but still For the whole circuit. We're going to need quite a lot of these The second part of the pre-processing phase we prove some correlations between these authenticated messages I'm not really going to get into this, but you can think of something like multiplication triples for for MPC in the online phase then we do something similar to The other talks have been here. We use these pre-processed values along with some very simple protocols in order to evaluate the circuit on the actual input, okay, and The important thing here is that we don't really use any crypto primitives in the online phase So the online phases is super fast. So Essentially something like 10% of the time is going to be in the online phase even less actually Okay, so since this is in the pre-processing phase is where we do the most kind of heavy lifting I'm going to Focus on this For this talk and I'm going to focus just on how we get these random authentications So let's look at These max that we use so the setting is that we have Bob here will have some global key delta which is going to be a random string the length of the security parameter and Then for every message that Alice has X Bob is going to have a local key K Which is also just going to be a random string and the Mac is then K X or X times delta and To argue that these max are unforderable Let's first see that the Mac does not actually give us any information on Delta But if we let M0 be a Mac corresponding to a zero message and M1 be a Mac corresponding to a one message We see that if we know both these max we can easily compute the global key. So somehow intuitively Forging a Mac should be as hard as guessing this Okay, so how do we get such a Mac? So this is the functionality we want it's pretty simple We call it an avid because it doesn't indicate spits So we want something where Alice inputs X Bob inputs a local key and a global key And then we just get out these The Mac like I defined it before and we want to implement really a lot of these these guys Okay So these are to the two steps of the protocol that implements this so first we obtain a few very very long Macs for Alice's random bits, and then we're going to turn this into a lot of Short Macs on on Bob's random bits. Okay, and this is where we use this OT extension thing of Isha Adele It's something very similar to their their protocol So to authenticate These bits we're going to use the OT functionality. So What this does is that? Bob will have two messages as zero and as one that he implements to the functionality Alice will input a choice fit C and then out of the functionality will come the message that that Alice chose Okay, and no one learns anything now for this particular application We need the messages to be of length T where T is some large value essentially any polynomial in security parameter So kind of the naive approach to doing this Authentication would be to just have Alice input the bits that she wants to authenticate and Bob would input the two possible Macs and The oblivious transfer would then output the Mac that that we need However, we need for Bob to use the same global key Delta here for each one of these and OTs so we need some way to force him to do that because if he's actively corrupted obviously he could choose a new global key every time Okay, so this is our problem and the solution is that We will actually just use the naive approach to authenticate twice as many bits as we need and Then we're going to use some cut-and-chat choose like technique in order to force Bob to use consistent deltas Now unfortunately this will sacrifice half of the authenticated messages that we get but it's okay because the other half is going to be good now I call this a cut-and-choose like technique because Kind of the good news here is that while Sort of half of the messages will be revealed during this cut-and-choose the keys for still be remain secret. So Yeah, there are some details that I'm kind of hiding here, but you can Okay, so now for step two Here I've written up these n max that we created in step one in this nice matrix form where you can see there are these long Column vectors are the first thing you'll do is just swap the position of the max and the keys and we see this Equation still holds the next thing to do is to kind of tilt our heads a little bit and instead of looking as things as Columns will look at them as short rows I'm going to do some renaming the first rows here I'll call N and L and Over here. I'm going to take this vector of X's X1 of 2xn and just call that delta and These are excuse me gamma or and these delta bits delta 1 to delta t. I'm going to call those y and What we see then is that this? Equation here in the bottom is going to hold Which basically means that we can look at ni as being a Mac on Yi under the keys Eli and gamma so now we have our short max for Bob So just to give a quick summary of what happened here We took a few otees with long messages. So 2n otees with messages of length t Then we implemented n Long max for Alice so max of length t n of those and then those we turned into Many short max for Bob. So t max of length n And what you should notice here is that while these are short They're still the length of the security parameters, so they should still be hard to guess But yeah, so this is what I told you here But what I would like to note here is that actually the initial otees with long messages These we can implement using otees with short messages if we only have a pseudo-ren generator And at the other end of the chain here We can take these authenticated bits and then we can use those to implement Otees with short messages Just using a hash function or something like this for every For every otee that we want So if we look at the whole chain we get this this ote extension technique that I told you about in the beginning Okay, so yeah Finally, let's just conclude. I wanted to find some Takeaway messages for you here. So the first one is you know, finally we have a non Garbled circuit approach to a practical 2pc. So yay, that's fun Well, it's based on GMW and ote extension. It's maybe less exciting, but you should remember that as well It's really fast. So I mentioned that it we were beat a little bit, but still You know Very nice protocol So if you're planning to implement some 2pc protocols at any time soon, I think you should try So this is all I have to say, thank you