 So I'll be talking about the non-interactive multi-party computation, and this is joint work with Shia Levy, Uwabi Shiai, Abyshek Jain, I mean, Sakai, and Elon New Year from all parts of the world. Okay, so I'll be talking about multi-party computation. We all know what it is, but I will say it in one slide. So in multi-party computation, there's a set of layers that don't trust each other, and they want to compute some function on their inputs. So each layer has some input that he wants to keep private, and still he wants to be able to compute some function on all the inputs while preserving privacy and, of course, making sure that the computation is correct. So this is a multi-party computation. In this talk, I'll be interested mostly about malicious security, meaning that the parties can be malicious and send any message they want in time without any restrictions, without even following the protocol. Of course, as you know, there's lots of solutions starting from information theoretic solutions that do not require any computational assumptions, and all the way to computational solutions based on lots of assumptions, cryptographic assumptions, and some of the solutions require correlated setup or some trusted form of setup, or some solutions do not require any sort of setup, and the more assumptions we have, basically we get a better protocol, and it can be in terms of the corruptions that we can tolerate, or it can be in the number of rounds the protocol lasts, or it can be in the amount of bits that each player sends, and so on and so forth. So the more assumptions we have, the better protocol we get. In this talk, I'll be talking about a very restricted setting of multi-party computation that is called non-interactive multi-party computation. So this is a very, very limited setting in which parties are completely asynchronous. Each player wakes up at some point in time, sends a single message to an evaluator, and that's it. It goes back to sleep, without saying any other message that any other player sends. So this is a very restricted setting of MPC, and it's not even clear that it's possible to do anything in the setting, this setting in which each player sends a single message to an evaluator is called, and maybe the configuration of the players is called the start pattern. I'll be talking about other configurations in the end of the talk towards the end, but this is maybe one primal example, which is, I think, very interesting. We can talk about other configurations, maybe most notably the chain where each player sends a message to the next player in the chain, I'll be talking about it next. And one interesting property of this very limited setting is that each configuration of the players gives you a different possible notion of security that you can achieve, and we call this the best possible notion of security, which is what I'm going to describe next. So think of a scenario in which you have three parties holding inputs x, y, and z, and they wish to compute some function on their inputs, some f of x, y, and z. And let's assume that party three is corrupted, and it's colluding with the evaluator. So what can happen? So since each player wakes up at any point in time you want and sends a single message, then basically the evaluator that colludes with the third party can compute any function of the form, any value of the form, f of x, y, and any value z that he wants. So it's a very strong attack that the adversary can do, and therefore we cannot hope to get very strong notion of security, like in the classical setting. And if you think about it for two minutes you will see that if you're aiming for a simulation based notion of security, and you want to support any function, then this will be impossible. Why? Because this notion of non-interactive multi-party computation implies a notion of obfuscation called virtual black books, and we know that this is impossible if you want to support any function. So we have to resort to a new capability based notion of security, which says basically the following. If party 3 is corrupted and colluding with the evaluator, then for any x, y, which are the inputs of the first and second player, and x prime and y prime, which are a different set of inputs to the first player, if the residual function, namely f of x and y are wired inside a non-disease free particle, if the residual function is equivalent for x and y and x prime and y prime, then the adversary that colludes with the third party should not distinguish whether the input of the first and second players was x and y or x prime and y prime. So this is a standard indistinguishability notion of security, and this is what we're going to be talking about. The notion of residual function has been studied for maybe six or seven years. It was introduced in the work of Halel Bili in the Lepinchas, and it has been very widely used since in the literature about function encryption and indistinguishability of execution. So this is the notion of security we're going to aim for. It's known because similarly to the equivalence of a simulation based security notion to VVB, it's not hard to see that an indistinguishability based notion of security in this setting implies indistinguishability of execution. So if we hope to support any function in this setting, we better assume indistinguishability of execution. So this will be a necessary assumption. Now we talked about the assumptions that we need in terms of hardest. Let's talk about the assumption that we need in terms of setup. What each party should, what we should assume about the setup of the system. So a first observation which is trivial is that each player must authenticate its input. If a player doesn't authenticate its input, then the evaluator can pretend to be that party because there's no way a party can generate an input if it's not authenticated that the evaluator cannot. So evaluator can pretend to be some input, the sum player, generate any input he wants and break the security of the scheme. Here's an example. Consider again the same setting, three players X, Y and Z, and only player three is colluding with the adversary. If the second party doesn't authenticate its input, then the evaluator can generate a message that looks like a message that the second player sent. Let's say this message is called Y star, and if by chance Y star splits the value of F where X is hardwired inside, then he can distinguish X from X prime. So this means that each player has to authenticate its input, which means in some sense we must have some public infrastructure. So setup is necessary in our setting, at least a public infrastructure. Another solution for this problem of non-interactive MPC, they required much more setup assumptions than just a BKI, and let me review what's going on in previous words. So the setting of non-interactive MPC was introduced by Fagy Kylian North a lot of time ago, and their setup assumption was actually pretty good, so they didn't assume almost no setup except a shared private stream between all players which is a secret to the evaluator, which we can implement using a BKI in some sense, but their solution is completely non-collusion resistant. So even if a single player rules with the evaluator, then there's no security in their scheme. And more modern works that rely on IO, which is necessary if you want to get a solution resistance, they have a strong setup assumption. They all rely on something called correlated private readiness. And what this means in the very simple language is that there is an additional trusted party, which is not part of the game, that before the protocol begins somehow generates an obfuscation of some circuit and publishes it so everybody can see it. So this is a very strong set of assumption on the setup, because who is this trusted party that is going to obfuscate some circuit? But on the other hand, their schemes are very secure in terms of collusion resistance, they're fully collusion resistant, they're the best you can go for. So this raises the question, can we get full collusion resistance while assuming the minimal set of assumption we can? And this is our result. We almost completely answered this question. We show protocol which is fully collusion resistant, so any amount of players can collude with the adversary. The setup that we need is a PKI, which I said is necessary, and we also have a CRS, common random stream, not the reference stream. And the hardest assumption that we require are IO, which as I said is necessary, and we also need the DDH, the decision of the field one, both sub-expansion security. And the first comment I'd like to make on the result is that the PKI we have is reusable, so we can reuse it over multiple sessions of the protocol, so we can do it again, we can send more and more messages with the same PKI, you don't need to re-sample the PKI. And of course getting rid of the DDH assumption is an open question, which I think is very interesting. We have several extensions and implications of this result. The first one is a notion that we call multi-party obfuscation. It's a variant of multi-party computation, but how the inputs of the players are modules of code and not inputs for a function. So each player can, in this notion, each player can take its code or some module that it wrote at home obfuscated in some way, send it into the evaluator that can take all the modules and compile them into one big program without revealing any information about the underlying motors. So this is what we call multi-party obfuscation. And another extension that we have is that I said that I mentioned the result for the star pattern in which players send a single message to the evaluator, but our techniques generalizes to any interaction pattern, so you define any graph that you want, in which parties communicate according to the edges of the graph, and eventually somehow the output should get to the evaluator, which can support anything with the same assumption, and we get in any setting the best possible security for that interaction pattern. I'll talk about it a little bit in the end, and then I'll talk about it. Okay. So this is the result. Let me talk about the techniques for a couple of minutes. So we heavily use a notion called multi-KFHG. In multi-KFHG, here's what it gives us, what it advises. We can sample a sequence of n encryption keys and encryption keys, so EK1 until EKN, and EK1 to EKN. So we can sample a sequence of n encryption and encryption keys. We can encrypt the message according to each encryption key. So we can encrypt X1 according to EK1, X2 according to EK2, until Xn according to encryption, the last encryption key. And yet a sequence of n ciphertexts. Using these n ciphertexts, we can take the n ciphertexts and move them or re-randomize them into a ciphertext of the same message, but under a common key. And the common key is just, you can think about it as the combination of all the encryption keys. So this is just a re-randomization procedure that takes a ciphertext under one specific key and transfers it into a ciphertext under the concatenation of all the encryption keys. Then once we have all the ciphertexts under the same key, we can do any homomorphic operation that we want. So we can take the sequence of ciphertexts and do some homomorphic operation on them and get the ciphertext of the homomorphic value, of the evaluation of underline values. And then we can do another operation which is called partial decryption. So what this operation gives us is that each player using only its decryption key can in some sense peel one layer of the encryption and get some sort of a partial decryption which is without his key in some sense. So each player can take the ciphertext which is under the concatenation of all the keys and peel one layer of the key. Then using partial decryptions, the sequence of all partial decryptions, there is a completely public operation that's called final decryption that takes the partial decryptions and gives you the value. So this is completely public, you don't need to let me see really quickly. So this is what a multi-key feature allows us to do. There are many properties that it satisfies. One of them is that the size of the ciphertext of any value of the ciphertext should be independent of the size of the function that we evaluated. Or at least depend on your own set and the size. That's like in any FHG. The security that we have here is in addition to just semantic security of encryption, we also have a security notion that tells us that there should be a simulator that can generate partial decryptions without knowing the secret key of some specific layer. So there is a simulator that doesn't know the key of the i-th layer, knows the output of the computation, and can generate a simulated partial decryption for the i-th board. So this is what the security of this notion gives us. And there are many instantiations starting from the original ones that were based on LWE, and there's a newer instantiation of DoDiCetal based on IO and DDH. They offer various different trade-offs between exactly what's going on. I'm not going into that. I would just say that we're using the scheme that's based on IO and DDH, just because it's more compatible with our assumptions. But we could use also the schemes based on LWE. Okay, so this is multi-key FHG. Now that we have this primitive in hand, let's see how the scheme works. So let's start with the honest case where there's no pollution. It's much easier. So party i will just sample an encryption key and the encryption key for the multi-key FHG scheme. This is pretty straightforward. And the message that party i will send is just an encryption of its private input under the encryption key, and an obfuscation of a circuit. So this is where we use IO. The circuit, what it does, is very simple. It just does whatever you expect it to do. It takes the ciphertext as input, it expends it into the expended ciphertext. It does the homomorphic evaluation, and eventually it does the partial decryption. It has hardwired the decryption key for the partial decryption. So that's what you expect. No surprises here. There are many issues with this idea. First of all, the expended operation is randomized. So we need to somehow support randomization. That's easy, because we, that's easy given the literature on IO. We just use a PRF, we just use a PRF to sample the randomness, and hope that IO will grant it security. So that's an easy issue that we take care of. The second, which is slightly more problematic, is the authentication. I told you that each player should authenticate its input, and I didn't authenticate my input here. So we add a signature scheme. So the key of a party will not be only an encryption key, an encryption key of the multi-key FHG scheme. But it will also be a signature key and a verification key of a signature scheme. The circuit will verify the signature, of course. So that's the whole honest scheme. Using a signature scheme is not revealed with IO. It introduces lots of problems. So we design a special signature scheme that allows us to make the proof go through. I don't think it's very interesting for this though. But you can see the details in here. How does the proof work? So the high level idea is to eliminate the encryption key from the obfuscation, right? That's the only secret thing in the obfuscation that I described. So we're going to do a sequence, a very long sequence of hybrids, in which we use the simulation of the simulator of the multi-key FHG scheme. Go input by input the circuit, and eventually get into a circuit in which we don't have the decryption key of the high player, but only use the simulation, the simulator to sample an instinctive value. So that's the idea. Each step in this hybrid proof uses the security of the puncture PRF, the IO, the multi-key FHG simulator, and some other things. That's how the proof looks like. It's very similar to a proof that the Anantatal had in the context of combiners of obfuscation. It's very similar. OK, let's go to the malicious case, which is the main focus of this work. So what happens if the adversary is malicious? The first problem that you run into, which is basically the only problem that there is, what happens if an adversary sends a ciphertext which is completely messed up, like a malformed ciphertext? What does partial decryption give us if the ciphertext is malformed? What will the simulator guarantee if the ciphertext is malformed? It's really not clear. So what we do is we add zero-knowledge proof. That's what you expect to do. So each player will send, in addition to the obfuscation of the server, will also send a zero-knowledge proof that proves that the ciphertext is a legal ciphertext. But again, using a zero-knowledge proof in the context of IO is not always easy. So the technique that we know is to use something called a simulation sound, a statistically simulation sound in non-interactive zero-knowledge proof. That's the standard technique in the IO literature. But this is still not enough for us. And the reason is that the adversary can plug in, in the coordinates that he controls, he can plug in any value he wants. And if he plugs in any value he wants, we cannot use the simulation of the multi-key FNG, because we need to know the output of the computation for the simulator. So how would we know the output of the computation? So for that, we construct something we call a statistical simulation extractable non-interactive zero-knowledge, which allows us, in the proof, to extract the secret key of the malicious parties and gather the proof of the value and compute the value and know the value of the computation in the proof. So this is the technical challenges we had. So we construct this special zero-knowledge proof, and this is what it allows us to do. So this is how the final circuit looks like in the malicious setting. So we get now, not only a ciphertext, we get also a proof and a signature. The circuit first verifies the signature, then verifies the proof, and then does exactly what they did before. Expands the ciphertext, does the homomorphic evaluation, and outputs the partial encryption. So this is the scheme. Let's talk about, for a couple of minutes, about other interaction patterns. The same idea generalizes to any interaction pattern. Maybe the most interesting one or the most natural one is the chain pattern. So think of end players sitting on the chain. Player i sends a message only to player i plus 1. And eventually the end player sends a message to the value. This is the interaction pattern that we allow. And the natural question is whether we can support such an interaction pattern. Whether we can do multi-party computation restricted to this interaction pattern. And our result generalizes immediately to this setting. The only difference is now the circuit, instead of getting all the ciphertext, will get only the ones from the future. And we will hardwire into the circuit the ones from the past, from before you mean the chain. So that's the same, but that's the idea. The conclusion of the work is a construction of a collusion-resistant non-interactive multi-party computation protocol. The setup assumption is the PKI and the CRS. The computational assumptions, the hardest assumptions, are IO and in this decision on the field with substantial security. And two very natural questions is to get rid of the DH assumption. And I think it's very interesting to devise protocols for specific functions without such strong assumptions. That should be a very interesting question. I'm sure research is the second point for specific personalities. So do you have some specific example for this? Yeah, so I think it's not hard to say, think about it for a couple of minutes, that you can do like a protocol for, let's say, computing the sum of the inputs of the pairs, almost without assumptions. Like, you need the very mildest, you don't need IO keys. Can you do something more than computing maybe the sum of the products? Can you compute a very simple circuit, like that two circuits and that one circuit? Simpler functions. Any other questions? Yeah, so let's answer PKI me.