 It's about reactive gobbling schemes by Jasper Nielsen and Samuel Lannicheli, and Samuel will give it all. Yes, thank you very much for staying for the last talk. And this is joint work with Jasper Nielsen, and I'm gonna talk about reactive gobbling schemes. So in this presentation, I'm gonna talk about our result. And our result is, three main things, is first we define reactive gobbling schemes. And then what we can show is that using reactive gobbling schemes, we get reactive two-party computation from reactive gobbling schemes, and it's blackpox against a malicious adversary. Now, one thing to note is that previous protocols for two PC don't actually use gobbling schemes in a blackbox manner. They actually have to use whitebox details about the gobbling scheme to actually get security. And then, of course, we have a result that we can construct reactive gobbling schemes in the random oracle model, but for this presentation, I'm not going to go into that. So what is reactive computation? So first we have, initially we have a state which is just zero. So we have a state, and we have a round which will start at round number one. And then at each round, so at round I, the first player inputs a function and an input X. The second player puts in an input Y, and then the functionality outputs, has an output Z, and some V, which is sort of gonna be added to the internal state, which it computes from F, X, Y, and the current state. Then it's going to actually update the state for the next round, and then it's gonna output both the output value Z and the function two P two. So this is reactive two PC. And so now we're gonna talk about what a gobbling scheme is, first of all. So we can do a quick recap of what that is. I already assumed some familiarity, so this is just a reminder. So what do gobbling scheme achieve? Well, this comes from basically it's saying, okay, we had a construction called Yau's Garbled Circuit, and it achieved something, but this something was never formally specified in the original paper. So Bilare, Huang, and Rockway came up with a definition of gobbling schemes which showed what gobbled circuits realized. So now the next question which comes to mind is, why did they define a gobbling scheme? Well, there's two principle reasons. So first of all, if you have a protocol that uses a primitive in a black box fashion, well, that protocol is more likely to be secure because then you don't have to care about the implementation details under. And the other thing is also because of this you can easily say, okay, this implementation is better in this case and this implementation of this primitive is better in this case, and then you can choose without having to worry too much about security. So there's many applications of gobbling scheme, secure outsourcing, secure computation, private function evaluation. There's many more KDM security, for example, and it's a very important. So just to remind you quickly what a gobbling scheme is. So this is what would be completely insecure protocol for gobbling. So initially the sender sends a function f to the receiver and then later on he sends the input x to the receiver and the receiver sends the output. Now, what we actually want from a gobbling scheme is three properties typically. First of all, it's correctness that it gives the right output, but we also either want privacy which means given what we gobbled, the receiver shouldn't learn the function or the input and then obliviousness hides the function, the input and the output. So these are properties. Okay, so global view of gobbling schemes, this is how a gobbling scheme typically works. First you gobbled the functions. This gives you an encoded function, an input encoding string so that you can encode some inputs and a decoding string which allows you to actually decode an output. And this is the description of function f and this is the security parameter written in unary. So then the next step is you encode the input. So you take the input encoding string, you take an input and it gives you an encoded output. Then the next step is blind evaluation where for example the second player can take the encoded function and the encoded input and produce the encoded output. And then finally you can extract the output using the decoding string and the encoded output. So this hides the output, this hides the input and this hides the function. So why did we define reactive gobbling scheme? Well, there's certain things that reactive gobbling schemes can't do. First of all, as you saw in the previous diagram, there's no partial input and output defined and sometimes it's useful for example to secure outsourcing to be able to provide partial input. You can't assemble garbled functions together so you might wanna garble one function and then another and decide oh I wanna apply f and then g or vice versa, for example in signal processing you might wanna do a certain amount of operations and sort in orders depending on the data. And you can't do black box constructions of two PC from gobbling schemes. This is something that was one of the original goal that Rockway wanted to do, that we build things black box from gobbling schemes but we can't. There are certain details that something that was missing and reactive gobbling scheme to give that. And then we also wanna reuse encoded output so we can get an encoded output and then feed it into another garbled function. So this is what reactive gobbling schemes allow us to do that gobbling schemes don't, they aren't. So how do we actually get a reactive gobbling scheme? So basically what we do is we take gobbling scheme and sort of expand the definition. So we're gonna do a couple of things. First of all we'll vectorize. So this means that instead of having one input we'll have a vector of inputs. And the same thing for outputs we'll have a vector of outputs. Then we'll have output encoding strings so ways that we can say how outputs are actually encoded. And this will allow us to do things. Then we have tags which is we need a way to say which functions we garbled and what they garbled to. So tags are sort of identifiers or names of functions. Then we have a linking algorithm which says how we can combine two garbled functions together, link them together. And then of course we need a new notion of security called confidentiality which is, yeah, so vectorizing gobbling schemes is very simple. So instead of having encoding a symbol input you can encode a vector of inputs. So you have an encoding for each of the values and then you have the coding for outputs. So you can decode partial outputs. You can encode partial outputs. So you for, yeah, and decode. So basically everything is vectorized so you can decode partial input, decode partial output. You don't need to wait till everything is defined. Yeah, so the evaluation takes partial input, partial encoded input and extract and gets out partial encoded output. So what's an output encoding string? Well, it just maps an output value to an encoded output. So it's very similar to the input encoding and it's going to be useful to link two garblings. So this is one of the key things in the reactive garbling scheme is the linking algorithm. So what it does is it take the output encoding string of one function and the input encoding string of another function. So this is like the function we're converting the output and this is the one we're sort of linking in and basically it gives us something called the linking information which basically what it allows us to do is takes an encoded output and to convert it into an encoded input for another garbled function. So then, of course, to describe which functions, so we know all we're garbling this function and when we're linking this function to this other function, well, we added tags. And so the garbling scheme takes an additional parameter which is a tag which sort of names the function. Now the garbled function has a tag, the input encoding has tags and the same thing for the encodings and then in addition there's a linking algorithm. So the linking algorithm takes the output encoding string. So this is saying how the output of a function is encoded and takes the input encoded of another function and then links them together. So now you can take the encoded output of one function and turn it into the encoded input for another garbled function. So then we have the evaluation procedure. It takes a set of garbled functions, a set of garbled inputs and a set of linking information and then based on that it actually just computes the encoded output. So the definitions are fairly simple extension of garbling schemes. And then because so obliviousness and privacy stay the same, so you're basically either hide the function or the output or you just hide the function and the input but then you have to worry about confidentiality. We extended basically some outputs that are encoded. You can only learn what their value is if you have a decoding for that partial input output. And this allows us, and this notion of confidentiality is actually implies both obliviousness and privacy because if you have no decoding information whatsoever then you're back to obliviousness and if you have all the decoding information then you get back privacy. So this implies this and this. So for example, just to see how it kind of looks like well you could garbled F and garbled G. So just you end up with two garblings. Then you can link G to F. So this is all it's doing. It's basically linking so it looks really nice. And then you can provide encoded input and then you can decode the output. And basically it can, you end up with something that looks like this. So visually it's very nice. So what are the applications of reactive garbling schemes? Well you have reactive two-party computation. It's a black box. So it only relies on reactive garbling schemes and not on its implementation. And it's gonna use the watch list. And we also have Lindell's cheater detection. So this was a technique that Lindell used to reduce the number of circuits you need to communicate by having a phase where the second player, if he learns that the first player cheated he's able to extract his input. And we can model this using reactive garbling schemes. And again it's in a black box fashion. And then we can also look at mini-legal as a type of reactive garbling schemes. Because mini-legal sort of this soldering is actually, in our language is actually this linking garbled functions together. So I'm gonna actually go in a little bit more detail about how you can realize the reactive two-party computation. So the idea is we're gonna have a watch list set up. So the idea is that we're gonna have many garbled circuits and we're gonna use half to verify that the first player is acting honestly. So this is basically making sure, okay he's garbling the right function. And then we're gonna use the other half for evaluation. And the way we're gonna do this is we're gonna evaluate all of them in parallel. And then the second player is gonna evaluate them and then take the majority output as the result. And the key is that if you, what we need to do is get the majority have the correct output, therefore you get the correct output. Unfortunately, usually there's two security, main security issues that we have to worry about when we're doing two PC protocols. The first one is input consistency of the first player. So one thing that you can have is when you have all these evaluations that are taking place in parallel. But it might be that the player P1 who garbled the circuits is sending different inputs to each one. So you need a way to verify that he's using the same input. And the second thing is the selective failure problem. And this one is the problem that depending on the input of the second player, the protocol might abort or not. And this is a problem that we have to prevent otherwise it leaks one bit of information. So how we enforce input consistency, well we're gonna use a special verification function. And the verification function, this is for the forcing that the first player uses consistent input, is that the function is gonna take the input of the first player as well as a mask for the first player. This is gonna be used to hide his input. And it's gonna take a universal hash function from the second player. And the idea is that this value, if the first player tries to use different X and X prime, this value is gonna defer between the different evaluations and the second player is going to be able to abort if the first player uses inconsistent output because of this property is that if X is different than X prime, then it's unlikely that the first player chooses an X prime such that this equation holds. So this is sort of gonna do this. So how are we gonna do this using linking? Well it's very simple. First we're just gonna garble the verification function. He's going to send input X and K. The first player is gonna send input X and K to the V. This is of course gonna be encoded. The second player is going to choose G at random and going to send into the function. Now he's gonna get the output and this is going to ensure that if for all the parallel evaluations they're the same, then accept with negligible probability, then he used consistent input. And then we're gonna actually link this function to the function we wanna evaluate and this ensures that we end up with an encoded input that's consistent for the sender. And to verify that this is all done, it's going to be enforced by the watch list. So it's very nice imagery. Now, selective failure attacks. Now this, how do we prevent? So we wanna avoid that his, whatever or not the P2 aborts depends on his input. So how are we gonna do this? Well the idea is that we're gonna garble an identity function. So this is going to and he's going to, the P2 is actually gonna choose a random input. And so this is going to be uncorrelated with his actual input at this stage. So this is random and then what we're gonna do is we're gonna actually use privacy amplification. So the P2 is actually gonna select a function h such that h of y prime is actually equal to y. So in this way he's going to use privacy amplification to hide his actual output. And so that even if there is an attempt at a selective failure attack, well the probability that it's going to abort is going to be independent of the receiver's output because we do this. And then of course we just link everything together. So then this creates an encoded y prime which because of the linking gets fed to the hash functions and it gives an encoded output y. And then this is fed to the functions we actually wanna evaluate. So just this linking allows us to prevent selective failure attacks. And both of these things input consistency in preventing selective failure attacks have previously been done by using white box modifications. And it's more most likely that it depends intrinsically on the properties of the garbled circuits. And you have to be careful because depending on your instantiation it might not work. So this, if you have a reactive gobbling scheme our protocol works. And in summary we extend gobbling schemes and then we can securely realize reactive to PC from reactive gobbling scheme in a black box manner and we actually have an instantiation. Thank you for listening. Thank you for staying for the last talk. And I'm happy to take any questions. Thank you. So any questions, comments? So if you had this notion of reusable gobbled circuits if you added like some linking capability and saving state that would, no. Yeah, pass state to the next evaluation. Any other comment or question? I have very basic question. Sorry if it is known by Erwan. Why do you need to hide a function F? Maybe one more question, comment. If no, let's thank to Simel again. So that's the end of the session and the conference. Maybe he will have some work. Maybe.