 Hi. This is interesting. I've never used this before. This, as he said, this is linear crypt. This is work with me and my advisor at Oregon State. And I'll just get started. So linear crypt is a special class of programs that captures some subset of practical cryptography in the sense that practical cryptography uses the one-way function and linear combinations of it, or some combinations of it. And that's all that linear crypt does. But having this requirement that we only use linear combinations of things we know, gives us the ability to synthesize many things, in particular garbled circuit schemes, like yows or optimizations to that, like free XOR. So this linear crypt model is similar to a mini crypt, but in mini crypt, there's only a one-way function that the only thing that exists is a one-way function. And you can use, and programs can do whatever they want with the results of those calls. But in linear crypt, the only thing you can do is to combine things linearly. So for it to be concrete, the only things that a linear crypt program can do are they can take some finite field elements as input. Oh, and by the way, a linear crypt program is embedded in a particular finite field. And they can also sample finite field elements. They can query the random oracle with a finite field element and get a finite field element in return. And then they can combine variables they know with a fixed linear coefficient. So for a concrete example, and also so you cannot get used to my notation, the first variable just takes some finite field element as input. The second variable will sample the finite field to get a new variable. The third one will query the random oracle at that point using this H notation to get a new point. And the fourth variable just takes a linear combination. They don't have to be just plus here. We just are fixed coefficient as one, but it could be any fixed coefficient. And we can return any number of variables. So using this, our main result is we show for any two linear crypt programs, we can tell whether they're indistinguishable in polynomial time. This lets us synthesize in the sense of automatically generate linear crypt programs that are indistinguishable from some specification. And we demonstrate this technique by synthesizing free XOR compatible garbage schemes. Did I skip one? Okay. So I've got three main parts in my talk. This talk will be telling you about how linear crypt works itself. And then I'll show you how we synthesize carbon circuits. So we want to tell whether two linear crypt programs have indistinguishable outputs. In order to do this, we'll need a few tools. We need to know how to express a linear crypt program as a matrix. And then we need to know how to trim that down to a canonical representation. And finally, we need to be able to reason about how the variables can be reordered. So I'll show you how to express a linear crypt program as a matrix. Here's a simple program. There's no security here. It's just an instance of a linear crypt program. We sample the finite field twice. We take a linear combination, query the oracle a couple of times, and return some stuff. But if you look at it, v3, v5, and the return variables are really just functions of these four lines in the program. And those lines are special. Let's call them base variables. The result of sampling the field or calling a random oracle, because the rest of the program can be based on them, I guess. So everything else is a linear function of these base variables. And then the whole program is a function of these base variables. How don't we represent this program as a matrix in terms of these base variables? So here on the right is a vector of the base variables themselves, and on the left is a vector of the internal variables. And then we just have to fill in this matrix to express the relationships. It makes sense that all the base variables are a function of themselves, so we can just assign them directly. And then the other two variables are some linear combination of the base variables. So they get the obvious choice. But this internal matrix, it doesn't really capture anything about the fact that when a distinguisher or an adversary, remember we're trying to be able to tell whether two linear crypt programs are indistinguishable. When a distinguisher has the output of this program, it doesn't have access to these internal variables. What it has is these two output rows, v4 and v5. So let's just use this as a representation. And we'll call this the output matrix. It's just the output variables. However, this output matrix is incomplete because there could be some correlations between the rows via the random oracle. So we need a way to account for these oracle queries. So that's where this oracle constraint structure comes in. The idea is simple. On the left-hand side of each oracle constraint is the vector for the query. And on the right-hand side is the vector representing the response. So for v4, v4 is querying the oracle at v3, which is v1 plus v2. So the vector is just v1 plus v2, and you get v4 out of it. Similarly for v5. Oops. So we show that the output matrix and the oracle constraints completely characterize a linear grid program. So now we can use linear algebra. Next I'll show you how to trim down this representation to get to some canonical form. First note that some of these oracle queries don't affect the adversary's view. If you see here, v6 isn't even included in any way in the output. And v4, well, it's reachable, but yeah, we'll see. I think I have an error here. Oh, no, never mind. Okay. So this first oracle query is unreachable from the output. There's no way that the adversary can reach this v2 variable. See, it has zeros down. It has zeros in this column. So there's no way it can get this one in order to query the random oracle at this point. And that sort of makes sense. This v2 variable isn't included in the output in any way. So the left-hand side of the oracle constraint is not in the span of anything else in the linear grid program. So therefore, well, in the output of this linear grid program. Therefore, this oracle query is indistinguishable from random from the distinguisher's point of view. So we can just remove it, and then it just looks random. And this doesn't affect the output distribution at all. Similarly, v6, v5 is reachable. It is literally the second output row here. So the distinguisher can query at this point. But the output of that is useless for trying to distinguish this program from anything else because it has zeros here. The output has this one in the v6 position, but this won't help at all. And this intuitively makes sense because you query at v6, but v6 doesn't appear in the output in any way. So again, we can remove this and it looks random to the distinguisher. So normalize is this function that removes these useless and unreachable oracle constraints. And it just removes the oracle constraints that don't affect the output. But there's a subtlety, and that's that these oracle constraints we allow for them to be adaptive. You can query at a point that is the result of a previous query. Here's a stupid program that's an example of that. You just query it. You sample at v1, and then you query at that point, and then you query again, but then you just return v1. So the output matrix is just v1, and then you have these two oracle constraints. So if we're just looking at the algebraic representation, we don't know. We don't know a priori whether these are reachable and useful. It looks like this first one, it's reachable, and then its output, v2, is used in another oracle constraint. So it looks useful. So we go to the second one. It's reachable since we already have this v2, but its output is useless. It's not in the span of anything else. So we can delete it. And that makes the first oracle constraint useless as well, so we end up deleting that, too. Keep skipping. So all this intuitively makes sense because you only return v1. It doesn't matter. These could do anything, and the adversary wouldn't know. So normalize builds these reachable and useful sets. And then just delete everything else that isn't reachable or useful. And we show that this is a normalized version of the program, is indistinguishable from the program itself. So next I'll show you how to reason about reordering the variables. So everything so far is talking about whether a particular vector is linearly independent of everything else. The left-hand side of a reachable oracle query is in the span of everything. And the right-hand side of a useful oracle query is also in the span of everything. So a basis change preserves these linear independence relationships between the vectors. And we could take a basis change on all of them and preserve all of the linear grip properties. And we show that this is the case. So now I think we're ready to show our main result. And that's that two linear grip programs are indistinguishable. If after you normalize them, they only differ by a basis change. You can find a basis change that brings them into alignment. And the non-trivial direction of this is by contraposition. We need to show a distinguisher for when there's no basis change that brings two normalized programs into alignment. We can't find such a basis change. And the way this works is let these be these blobs represent the vectors that each program has, the output matrix and the oracle constraints. And then after we normalize them, they come into some regular form. So inside these inner shapes, after the normalized spaces, every oracle constraint is both useful and reachable. But since they're different, since they can't be brought into alignment, there's no way to take this triangle into a square, there must be some oracle constraint that exists in one but not the other. So the distinguisher needs to find that oracle constraint and then query at that point. And then the output will be random if it's in the presence of the second program and the linear combination of everything else that it knows in the presence of the first program. And the proof itself is a lot more subtle than this and there's lots of complexities to see the paper. So this normalized function, it's kind of messy. We don't know how many times we need to iterate it in order to get to a canonical form. So this is bad for synthesis. We want to find some formula to give to the SMT solver. So that's where this basis change comes in. We've got a couple of tricks that will let us just use the basis change for things that we need for synthesis. In particular, checking whether a function is indistinguishable from random and for composing programs to check correctness. The first trick is for telling when a linear program is indistinguishable from random. In order for a program to be indistinguishable from random, there's two requirements. The first is that all the output vectors should be linearly independent of each other. Let's just say there's k of them. And the other requirement is that all of the oracle constraints need to be unreachable. Otherwise there may be some relationships between the output vectors. So we can check both of these conditions using a basis change. In the first case, if we can find a basis change that takes the output matrix to the k identity matrix followed by zeros. If we can do this, then the first requirement is satisfied since trivially all the output vectors are linearly independent. And then for the other requirement, there's another trick. If the rightmost n minus k elements of a particular vector are non-zero, if any of them are non-zero, then it's unreachable, given this output matrix. And that's because there's no way if you have zeros on the right side past the kth position, there's no way to get a one in the right side of a particular vector. So all we need to do is check that all the oracle queries have this property. And then we have the oracle constraints are unreachable, satisfying the second property. So our second trick is to use a basis change for composition. We need this because the base variables in the first program might not agree with the base variables in the second program, and we'd like to merge them. So if we can do this, then the output matrix for the second program is the output for the whole program. Here's an example. We've got a simple encryption scheme that just takes a random element from the field and uses it to query the oracle and mask the message. And then the decryption reverses that. And these are the algebraic representations corresponding to that. But note that their base variables are not aligned. We have an M where really we want or we have an R where in the wrong position it should be in the second. We have the C where actually we want M plus H of R, and H of R is fine. So we need these to agree. These output of the first program to agree with the input of the second program. And we can do that using this basis change. It takes R from the second program to the second or second slot. It takes the C to M plus H of R and H of R is fine where it is. But we also need to make these oracle constraints line up. They need to agree. H of R in the presence of the first program should mean the same thing in the second program. So I will apply this basis change and we get this result. And it simplifies to that. Now the oracle constraints are in agreement. We change those in agreement and we just output the second output matrix. And that is composition. So this basis change as a bonus is a witness to the correctness of this scheme. So next I will show you how we use linear crypt to synthesize garbled circuits. We are in the free XOR land where there is a global delta constant that is used to represent the true wire labels. And our security in linear crypt reduces to whether or not this delta is reachable by the adversaries view. So our approach is to guess garbled and eval for a single gate. And we show that if you can garble a single gate in this context you can build a whole garbled circuit scheme. Then we guess a basis change. And the basis change will be used to check the correctness by composing garbled and eval and making sure you get the correct wire labels for all of your input combinations. And then we will check security by ensuring that delta is unreachable from the adversaries view. And then this basis change itself is a proof of correctness and security. We give everything to a SAT solver and then the witness is a scheme. And if it is unsat then we have a proof of the fact that it is there is no such scheme for the parameters we chose. So I will show you our results. Oh yeah, we were trying to beat half gates. We wondered if we could beat this half gates. It is an optimization that shows that you need at least two ciphertexts to garble an AND gate. And we wondered if we could do better. So we implemented it in Python. It uses the Z3 SAT solver. It runs on my laptop. It is available for free from this URL. The way it works is you give it parameters that represent the size of the garbled table the number of oracle queries you can make and these all in turn affect the size of the matrices that we will generate. And then we create SAT variables for every element inside those matrices. And then we write the security and correctness formulas from the previous slide in terms of these matrices of SAT variables. Then we give the whole thing to the SAT solver and if it is satisfiable we just translate it into human readable form. And this is the table of our results. So this is the functionality we are trying to garble. So for instance we tried to recreate free XOR. Fortunately we were able to. This is the functionality. Here is XOR with two inputs a size zero garbled table with no oracle queries and we were able to do it satisfiable in one second. We were also able to recreate half gate and with two ciphertexts in the garbled table and four oracle queries in the garbler and two in the evaluator that was easily satisfiable. We tried to beat half gates by reducing the number of ciphertexts by one and we tried to beat it also by reducing the number of evaluator queries and garbler queries but both of these were unsatisfiable. So after that we tried synthesizing some more exotic schemes or exotic gates like a MUX gate, an equality gate or a comparison gate but this all sort of reduced to we need at least two ciphertexts for every AND gate inside of the functionality we're trying to garble. Here's an example of one of the half gate schemes we synthesized we can generate thousands of these just enumerate them endlessly it seems and there's two ciphertexts in the G1 and G2 are the two ciphertexts in the garbled table four oracle queries in the garbler two in the evaluator that down here um yeah the notation is tricky there's some subtleties with the color bits and permutation bits that we support and expand on in the paper and yeah read the paper if you'd like to understand this but I just wanted to show you what it looks like so in conclusion we have this result to be able to show indistinguishability of linear CRIP programs we used it to synthesize garbled circulate schemes we weren't able to be any um half gates or any we didn't make any improvements on garbled circuits but we were able to re-create everything and for future work we'll try synthesizing other kinds of garbled circuits we'll try applying it to other kinds of crypto and we will try other kinds of oracles as well