 Okay. The scope is very detailed, so I'll take you in here online. My friends have done this, and I'm starting. My friend is friends have done this. So thanks for the introduction. Yeah, so this is a joint work with Peter as a student. So what I'm going to be talking about is how to defend obfuscation constructions against a certain type of attack. And so currently obfuscation relies on multi-linear map constructions. And so in particular, in this talk, I'm going to be talking about defending obfuscation against a particular exploiting of the CLP. So first, I guess this is going to be a slight review of the previous talk, but I'll just briefly introduce what obfuscation is. So the question that obfuscation answers is how do you hide a secret inside the source code of a program? So we need a security definition for this notion. And the security definition word we can work with is the following one. So let's assume we have a procedure IO that takes a program source code that's in here, and outputs an obfuscated version of this source code. And so basically we want this procedure to scope the program of all these decouple features except for its functionality and its size. So what I mean by that is let's say we have two programs that are functionally overlapped. So in other words, they became identically on all inputs. And so we want the obfuscations of these programs to be extinguished. So we're going to be talking about obfuscations of a certain type of program representation called matrix branching programs. And it's known that if you can obfuscate matrix branching programs correctly you can obfuscate, you can construct that to obfuscate all polynomial size circuits. So what is a matrix branching program? You can think of it as a set of columns of matrices. And an evaluation to sort of make sense of this, let's talk about what an evaluation of this program is. So to evaluate the program we choose a matrix from each column based on a bit of the input. And we keep on doing this until we've chosen a matrix from every column. And then we compute the product of those chosen matrices and this is the output of our program. So for binary programs we can say that the output is zero if the product is the identity end and it's one of the lines. So given that, the idea behind most obfuscation schemes is that it's a two step outline. So the first step is that we take a matrix branching program and we randomize the matrices in some way, such that the products are all preserved but the values are hidden. And then the second step is that we encode these matrix values in a way that allows evaluations of the branching program but doesn't allow any other computation. So it turns out that a multilinear map is a really natural way to obtain the second step because what a multilinear map does is it allows you to encrypt values over a ring or a finite field in such a way that anyone can evaluate a very restricted set of polynomials over these values. So the problem with this outline or this strategy is that it's with the multilinear map itself. So every multilinear map construction that we know suffers from attacks. And in particular the CLT multilinear map candidate suffers from a class of attacks called 0SMU tax. And so these attacks are quite intricate construction and they rely intimately on the details of the CLT multilinear map. But we don't need, for the purpose of this talk, we don't need any of those details. So we don't need to know how the CLT multilinear map is constructed. We don't need to know the details of the attacks. All we need to know is that they all follow a particular pattern. And this pattern is that for doing an employee has the arising attack. We need three sets of encodings, A, B and C, such that you can choose any element from each of these encodings and multiply them together and get zero. So in other words, we have this three-wise product. And we need to be able to vary the choice for each component of the product independently of the other two choices and still get an encoding of zero at the end. So it's sort of like a cross product of products. So to apply these zeroizing attacks to obfuscation, we get a sort of parallel property, an interesting parallel property that sort of parallels the previous property that is to hold over the function itself being obfuscated. So we need to be able to partition the input bit indices of the function into three parts so that we can vary the choice of bits for each part independently of the other choices and always get zero. So these zeroizing attacks originally only knew how to apply them to a very unrestricted set of branching programs. But a year ago, Karan et al. figured out how to sort of greatly expand this set of honorable branching programs. And so these attacks suddenly became much more threatening to IO or CLT. And because of that, it's now quite interesting to try to defend against them. And so our goal is to do that. And the way we're going to do that is by explaining the fact that every attack requires this property over the input bits that I described. And so we're going to call it property input partition. And so we're going to show how to eliminate input partitions and thus secure obfuscation over against zeroizing attacks. So one key point is that an input partition is not a property of a branching program. It's a property of the function that's being represented by the branching program. And so to prevent an input partition, we can actually just change the function that's being represented slightly. And that's sufficient. So we're going to have to do this. And we're going to do this by introducing a hash like function h that we're going to call it an input set. And we're going to do this transformation, the following transformation. So we're going to take a function f and we're going to produce an f prime that takes an input f and a stamp y. And it's going to check whether y is the correctly computed input stamp of the input. And if that's true, it's going to output the original output f. Otherwise it's going to just output some arbitrary amount of zero value. So note that this is constraining the ways that somebody can obtain a zero from this function because now not only do they have to find an x such that f of x is zero, they also have to correctly compute this input h. So we're going to call this transformation securing a function f. So the main result of our paper is a necessary and sufficient condition for a function h to successfully secure any function f. So to successfully prevent input partitions. And so for the, just to stop it, we can actually describe a simplified version of the main theorem that's a sufficient condition. So I'll refer to the paper for the full, the resultant's full swing. So this result is a sort of non-punary. So let's choose points x1, x2, x3, and x4, such that difference between x1 and x2 is the same as the difference between x3 and x4. And so it is the case that h never preserves this difference in quality for any choice of x1, x2, x3, and x4. Then h will secure any function f. So if you find such an h, that means you have a difference against zeroizing it. So now our goal would be to just construct these functions h. And so since this is a very arithmetic property, it's natural that a lot of numbering theoretic functions, so you can actually find a lot of numbering theoretic functions that satisfy this property. One such function is this very function minus some large quantity. And it's very intuitive why this might hold because this very function is obviously never linear at any point. And so it's very easy to show that it satisfies this non-miniarity property. So the problem with number theoretic functions is that branching programs don't support arithmetic operations over their inputs naturally. And so because of that, these number theoretic functions tend to not be efficient. And so our last contribution is to construct a very efficient combinatorial function that secures, that events it in the branches. And however you do this is actually going to use the probabilistic instructions thoroughly to define a family of input stamps h. And then if we choose input stamp at random of this family, this function is going to secure all function f with very high probability. So the idea behind this construction is just we're going to observe the behavior of a completely random matrix branching program. So let's say we have a sequence branching program where we choose all the matrices to be random permutation matrices. So if you fix inputs x1, x2, x3, x4 where the differences are equal, it turns out that over the choice of a random branching program page the probability that our non-linearity property holds over this particular fixed set of points is non-languageable even for a small fixed k size of the permutations. And so we can use this in the following way. So there's a technique that's kind of a literature to evaluate many branching programs in parallel over the CLT of the AMF. And so we're going to use this and we're going to evaluate many independently sampled substations of our random branching program. And then we're going to use this to define a new function h. And the output of this function is just the calculation of the outputs of all of these random matrix branching program. And so we can use the unit, we can use any new background to show that if t is larger than this combined function h is nonlinear over all the choices x1, x2, x3, x4 with very high probability. So we can do a bit of analysis to show that this new function h can secure any function f with a linear flow in the size of the branching program being opposite. So yeah, so in terms of future work, from my representative just posted, I guess a month ago, a picture of where they did a new weak mobility model for CLT mobility model. And they show that this mobility model captures all of the known attacks on the CLT mobility model, the zeroizing attacks. And they also show that the standard dual input optimization techniques are secure under this weak model. And so I think it would be interesting to sort of see what these two results could do. I think I maybe missed something. So you're sort of changing f so that it only sometimes outputs the right value. So have you noticed that your products get served as the greatest product? I mean, you want your program to work correctly on all of this. Yeah, so given f prime is always possible to obtain a competition better. You just have to, I mean, so you take the input x that you want to compute f over and then you just, you yourself compute the hash value h. And then you put this combined value into f prime. I'm thinking of an off-scatter program. I've just got this thing and I'm running a lot of changes to design in the pipeline. And then you just give it to you in the protocol. Let's say you give it to you in the protocol and you take x, you compute h on the protocol and then you have this x and y and then you put that into your protocol. Ah, I guess. Yeah, thanks. Good teamwork. Any other questions? Okay, let's start to speak again.