 Okay, thank you for introduction. Thank you. I'm going to talk 9 useful interactive computation with Melissa, Yofgeny, Yubao, Daniel, Ruffle, and Vinod, and Tianren. And so... So there are two parties, senders and the receiver. I was considering the problem of, like, each party has an input, and the one-led receiver knows the function of their joint input. Okay, so it's called 9 interactive, which means it's a two-message protocol. The receiver sends the message to sender and the sender returns the message back. The receiver knows the output. So, for example, if you have the homomorphic encryption, you get it. Let the receiver send the encryption of her data and the sender do locally evaluation and send the encryption off to back. Okay, but... homomorphic encryption is quite inefficient. So, the more practical one is using Goblet-circuit and OT. So for Goblet-circuit, for any input the sender has, the sender can compute the Goblet-circuit and also two tags for each input wires. Such that, if you also consider the receiver's input and give the receiver the Goblet-circuit and the corresponding input tags, they jointly review the output and nothing else computationally. So this lead to, directly lead to a protocol, an ISK protocol, that the sender just send the Goblet-circuit in plain and also use obvious transfer to send one tag of input wire. Okay, so far so good, but this part have many advantages, like they enjoy, they use all the different OT realizations and the different assumptions and the different models. It's quite efficient. And also by like Yuval, Errol, Ruffle, Manage, and Emmet, they actually make this protocol maliciously secure. But what I'm going to talk about today, it's reusability. So this protocol is not reusable. What does reusable mean and why do we care about it? When you go back to definition, you should consider that the first message is not sent to the sender. The first message of the receiver is just some public message. You can publish on your favorite social media like Facebook or Twitter, so that the sender can just grab your message from your Twitter and send your message. And then the receiver gets the output. For reusability, we want the receiver doesn't need to post a new Twitter every time she use this protocol. So when new sender comes, he can just read the Twitter and use the same message and send the receiver a message, and the receiver should also know the corresponding function outputs. So if you care about correctness and the same on security, it automatically goes through. But when you consider malicious parity, in particular, when the sender is malicious, things become quite tricky. So when all the sender are malicious, in particular, they can send multiple messages to the receiver, and they can learn the receiver behavior after the receiver gets the message, and also they can send new messages adaptively. We want the protocol to be secure even under such attack. So what goes wrong with the old protocol? In the code mode protocol, when the sender is malicious, say the sender replace one of the input tags with some trash. And then if the receiver gets this trash, the receiver would behave accordingly, and the sender might learn that. If the sender found, oh, I changed this input to trash and the receiver's behaviors changed, he know the corresponding input bit and which violate the security. But you can do some patch on it. Like you can, instead of fit the input in plain text to the old protocol, you fit some encoding of the input, such that like a few bit of the encoding doesn't leak any information about the inputs. This way you can make it, oh, sorry, this should be malicious security. You can make it secure in one shot, but not in the reusable setting. Because in the reusable setting, the sender can repeat attack and learn every bit of the encoding. Well, hopefully. In such case, like, although a few bit of the encoding doesn't leak input, the inputting in total would leak the input. And you might want to get some small patch, but our first theorem in the paper shows that it's impossible in the sense that if you only rely on OT, you cannot construct reusable NSE. But our first one, the attack curve is unbounded, so we show there's no information circle in OT hybrid mode. We also have a theorem shows that if you are willing to assume like there are black box simulation, there are like one function, you only consider certain functionality, and that's impossible. Okay. So a different route is from NSEK. The NSEK-based protocol, like the sender would prove that his message is only generated. But in this case, the protocols typically become quite inefficient because the NSEK requires non-black box use of all the prime tips. Okay. So to get run with that, we considered the arithmetic analog of OT, which is called the Oblivior Linear Function Inversion, or ORE, in short. In such case, there is a field or ring, F. The receiver's input is just one field element, and the sender's input is two field elements. The output is, okay, evaluate the receiver's input on the linear function specified by the sender's input. The first thing we show is like this functionality is complete for reusable NSEK. In the sense that in a reusable ORE hypermodel, you can construct information theoretical. Use is secure. Reusable NSEK. And of course, we also need to construct such protocol. We use a Pylier assumption we'll mention later in CRS model. Here, CRS means common reference string, so we need a trusted setup. So if you consider a bit, assuming the field is binary field, then ORE is actually equivalent to OT. This kind of contradicts with our previous result. We show that such protocol, it's impossible if it's the OT hypermodel. Therefore, it's not surprising we need the field to be super large, expansionally large. Our security laws, it's proportional to, it's roughly the one over the field size. Okay. Now I will give you a quite brief overview of how we construct this to CRS. So the first one, we want to use this as black box, and that's all we need to construct NSEK. We consider what if we only have one short circuit. One short means non-reusable. Okay. When the sender is malicious, he doesn't actually have a well-defined input. But in UC security, there's a simulator. The simulator reads the input, the sender sends to the ROLE oracle, and from that, the simulator can extract an effective input, such that the receiver should output fx, y star, where y star is the effective input. Okay. I will mention that for normal MPC, typically the receiver would abort, or some part of the abort when they saw abnormal behavior. But in this, okay, in the non-interactive settings, non-abort is free in the sense that whenever the receiver detects malicious behavior, the receiver can just pretend the sender used some default input. Okay. This is not very important. Okay. So why assume you have such simulator that is still not reusable secure? The simulator output might be a distribution. In such case, the receiver would output, also have entropy in the ideal world. And therefore, it also have entropy in the real world. This entropy is not coming from the receiver's input, because it's secure, one-shot secure. But it's coming from the receiver's randomness. But that's the problematic part. If it leaks the receiver's randomness and the sender repeats such a forecast, the randomness leakage would accumulate to a degree the protocol is normal secure. So therefore, the fix is quite simple. We want to construct a protocol where the simulator is deterministic. And then you check everything that works well. Like if you have one-shot security, a user's security and the simulator is deterministic, it's automatically used as secure for a reusable setting. So let's start with... Okay. Let's start with assuming everything is arithmetic. So the input for both parties is a vector over some field. And the functionality is an arithmetic branching program or an arithmetic NC1 circuit. We'll consider more general case by the very end of this slide. Okay. So by using randomness encoding by Ishaa and Kushi... Oh, sorry. Ishaa and Kushi-Levis, there's a randomness encoding that the sender can encode his input into a fix and a vector, such that a matrix A times the input of the receiver X plus B reveals nothing but the output. Okay. So if you only are satisfied with semi-honest, you can just use the OLE as black box and the receiver to the FX one. But when you... Okay. When the sender is malicious, we want to make sure, like, the matrix A and B is honestly generated. So in particular, we want to replace this OLE black box with something we call certified OLE, which is a super powerful primitive such that if the input on the sender set satisfies some constraint, it just evaluate the linear function. But otherwise, the functionality would inform the receiver, says, no, like the sender is doing some simulations. So basically there are some... If there's no certified... Like, it's just some plain OLE, but with the certified, we want the sender to be able to prove any arithmetic constraint on the coefficient heat truth. So in particular, this implies that doesn't require NISC in OLE heavy mode because you can prove any constraints. But for this talk, a generalized metric constraint is too hard. We only consider a super simple constraint we call the... Okay, so we only consider when A i equals A j for some I j. So this is totally simplified. For the general constraint, it's only in the E print. Okay, actually, even for this one, we won't fully cover it. So how does it go? To get the favor of our construction, the receiver choose some randomness and fit to one of the OLE or code. And the sender choose one of the coefficients and one random fill element, and the receiver get the AW plus R. So here AW star is this OLE output. You should view that as a commitment of A. Because, yeah, like, as you can check, later the sender can open the commitment by sending A and R to the receiver. And it's easy to track. This is the statistically sound and zero knowledge in OLE heavy mode. And say later the sender want to send A B, use A B as coefficients and X i as the receiver's input and let the receiver knows A X i plus B. So this is what the receiver should learn. In order to do that, the receiver choose a new randomness like for this index i. And he fit some encoding to the OLE heavy mode. And now the sender, okay, the sender choose something else. Let's not check the detail why we choose that. We get some new OLE outputs. And there's a magic equation. Actually, this equation is not magic at all. It's like if you want this equation to hold, you reverse engineer and you will find this is what you should fit into the OLE protocol. So let's check how well this protocol is. The correctness is obvious. It's just from the equation here. So for use of security against the receiver, when we have receiver's input, the simulator can extract the efficient output of the receiver. And for the use of security against the sender, it's a bit tricky. Actually, if the sender is honest, honest in the sense that if these two coefficients, he fits the same coefficient and these two, he fits the same coefficients, the simulator can extract the efficient input. But otherwise, if the sender debits from protocol, the simulator actually cannot extract the input. So we didn't prove use of security yet. But we can show that what the receiver would output when the sender debits the protocol is a purely random field element. So we want them even conditioned on the sender's field. So this is like the first step. And later we do a lot of things, like because this is purely random, we can repeat the protocol twice so that if they match, then we know the sender is not malicious. But then it opens the door for the receiver to cheat. So we actually, okay, we won't go to the Intel, but we go back and forth several rounds to get this minimum certified OLE. So this, down this minimized certified OLE, we construct the complete certified OLE. So this is all I want to give about the detail of the construction of certified OLE and our construction of an SK in OLE heavy model. The next I would give some brief overview about how we construct the two-message OLE protocol. Okay, so OLE is a smart analog of OT and for OT there's a nice construction by Packard, Unaut, and Waters. Our construction have a very similar failure with them. So the common random string can be chosen from two different distributions and that specify two different modes. In one of the modes, you can interpret the receiver's message as the encryption of his input. And therefore, like the, okay, the simulator knows the secret key of the encryption so the simulator can easily simulate the receiver's input. And the sender's message leaks no information under the X plus B. So in this mode, it's information so that it's secure against the receiver. In the next mode, by changing only the CRS, the receiver's message is actually an encryption of zero. And the sender message is the encryption of his input. So therefore, in this mode, it's easy to simulate and it's information circle against the malicious sender. And the two distributions are indistinguishable. So we also have computational secure against either sender or receiver. So for parallel group, we won't mention the detail. It's a parallel, oh, sorry. So parallel encryption is based on assumption simulator factory. But we just use it as a black box. There's a key generation algorithm we call the secret key trapdoor because actually in our protocol, no one in the real world are going to use this secret key. Only the simulator are going to use it. And there's an encryption decryption scheme. And when the randomness is zero, we don't need the secret key, we can directly decrypt. And more this scheme is somehow homomorphic in the sense that if you multiply two separatex, you get the separatex of the, you add two, yes, you multiply two separatex. You get separatex of their addition so the randomness is the addition of their randomness. Okay, this is all we're going to need. So in the first mode, we have the CRS has three encryptions. The first one is encryption for one under zero randomness. The other is just using fresh randomness. And, okay, the sender's input as I mentioned, it's encryption of his input. And there are a secret key only know by him. And there are a public key only know by him. Sorry, and the randomness only know by him. And yes, the sender just send a branch message back. And if you check, yeah, everything should work well. Oh, we found this. In the other mode, we just replace one of the CRS encryption with the encryption of zero. So the two CRS are indeed synchro. And correspondingly, okay, correspondingly the message would change. I want to mention something that at this time, the simulator can actually behave maliciously. You don't know whether the randomness still satisfy the right correlations. And in this protocol, there's no way to detect whether the sender is malicious. So actually, we need a different mechanism, not mentioned in the talk again, to detect whether the sender is malicious. So that's all I want to talk about, our OLE from Pyliar Group. So a quick summary of our result. We show that you cannot construct an SK in OT hypermodel without other assumptions. But you can do the same thing for OLE, sorry, in OT without other assumptions, but you can do the same thing in OLE hypermodel for a small arithmetic function. And also as a side product, you can get an SDK for any functions, oh, sorry, for any MP language. And by combining these two with Scarborough Circuit, you can get an SK for any functions. But this time, it's no more information security secure against the receiver. And eventually, we also have an OLE protocol from Pyliar Group assumption. And by compose the result we have, it means we can construct reusable SK and SDK in Pyliar model, sorry, under Pyliar assumption. And in particular, our construction, it's information security secure in the OLE hypermodel. And our OLE, it's one-side information security secure based on the distribution of CRS, which means to compose the one, it's also one-side information security secure. So in particular, the most interesting one is like, you consider an SDK that it's one-side secure, one-side information security secure against the receiver. And that means we have a, oh, sorry, this should be statistical. We have a statistical doesn't verify our NISC argument. And another feature of the protocol is like, because OLE is like a systematic analog of OT, you can actually make all the cryptography to the offline phase. So in the offline phase, you construct a lot of randomized, random OLE pairs. And in the online phase, you just, whenever you need OLE, you use this offline computed randomness information circling. So therefore the online phase is a non-cryptography and it's quite sufficient, quite efficient. The overall communication doesn't increase. So that's all I want to talk. Thank you very much. Is there any questions? Thanks for the talk. So I was wondering, can you comment on the efficiency of your protocol, like the complexity? Okay, so efficiency, okay. Maybe here the NISC protocol is quite nice because for each gate in the circuit, you only need to transfer a constant number of group element. But for NISC, it's kind of tricky. So we have two ways to construct NISC. One is the information protocol. But this one using the randomized encodings of NISC-1 circuit or branching program, which means it's only polynomial of the size of the branching programs. And the other one is using if you, okay, the other one is if you use Gabor circuit and you prove the Gabor circuit is un-generated. In this one, the communication would be probably a secure parameter for each gate. So I guess the follow-up question is that is there, do you think there's some hope of eventually have this protocol applied or used in practice? Okay, I guess if you compare with the approach from NISC-based one, for very small circuit, our protocol here might be quite efficient, maybe more efficient than there. But for large circuit, I didn't check the exact number which was more efficient. But I guess we also had the advantage of the online offline because if you use this online offline, then in the online phase, there's no public encryption even if you use the Gabor circuit approach, which could be quite efficient if you are using some big device. Thanks. I guess let's keep the other questions offline since we are running a little bit behind the schedule. Yeah, let's thank the speaker again.