 Okay, today I'll talk about multi-party computation, mainly, and on some automomorphic encryption later. Okay, so what we do is MPC protocol, secure against an active adversary, corrupting a dishonest majority, and of course the security is computational, and we choose to have this UC framework. And as you see, there are some other examples of this kind of work, early construction by Canadian friends, the MPC in the head approach, and well, the August team has this prepossessing model also. And okay, this funny reference, well, you'll see it in 40 minutes, and but today we'll mainly focus on this one, and on our work. Okay, so notation. So since our work is, compares very well with this Bedoza paper, I will say Bedoza when I mean Bendlin, Damgo, Orlandi, Zacarias, Eurocube 2011. And I'll say speeds for today, today's topic, and you can figure out what it means. Okay, so we both reached this MPC protocol in the prepossessing model, meaning that the MPC takes place into two phases, prepossessing phase where players engage in a protocol where they will get some shared randomness at the end. And later on they will engage in an online phase where they will compute the actual function to be computed. Fun fact, the prepossessing is independent of the function, so you can do it months in advance without knowing what you're going to compute later, basically. And another fun fact is that the online phase is extremely fast because you don't need public key encryption. That's very nice. So of course, two phases, let's talk about the online phase first and then on the prepossessing. So in order to understand our online phase, I'll have to make a digression on Bedosa's online phase first. So computation in the Bedosa paper is taken in, yeah, it's still dealt to in a secret share, secret sharing of values, of secret values. And by secret sharing, I mean additive secret sharing, and the IS share is given to PI. Security, on the other hand, is given by max on shares. So for every secret you have n shares, for every share you have n max. And player i will not only hold the value xi, but also the jth mech on the share xi for every other player PJ. On the other hand, PJ will hold the key for that mech. So throughout this talk, I'll denote by bracket x this situation, meaning share i is given to PI and the max and the keys are given accordingly. Good. So we want to compute any algebraic function. So if you have an algebraic function, you can decompose it in sums and multiplications. So let's see how to compute sums first. So that's easy. Since the secret sharing is additive and the max are linear, you can do everything locally, meaning that to compute the sum of bracket x plus bracket y, players will just add their shares locally, their max locally, and the keys locally. What about multiplication? That's slightly more advanced. So we use the beaver trick. If you are given some multiplicative triples, meaning a bracket representation of a random value a, b, and their products, then you can mask x and y via a and b using the addition protocol. And then you can reconstruct these masked values and compute a value z as the value a times b minus b epsilon times minus a delta times plus the constant epsilon times delta. And you do the math, z is equal to x times y. So in the below paper, notice this. There is a MAC checking every time there is a reconstruction and this is something different than what we do. Okay, so computation in their case, well, let's see the philosophy of the protocol. So linear secret sharing schemes and MACs will allow you to compute additions, multiplicative triples will also allow you to compute products. For the security part, the secret sharing will give you privacy and the MACs will give you authenticity. And the complexity of this online phase is the following. For every secret you have n shares and for every share you have n MACs and keys. So you need a square amount of field elements for every secret. Can we do it better? Well, yes, we can do it. So notice that in the bedosa they use MACs on the shares in order to authenticate the secrets. So what we were thinking was, well, we could do something else maybe. And yeah, we sat down for a while and we decided to use the MACs on the secrets in order to authenticate the secrets. So we define another representation for values. So we assume we have a bracket notation for alpha, one single values for all secrets. And we define this angle notation for the secrets, meaning additive secret sharing of the value and additive secret sharing of a MAC on that value. And the data needed per secret is then linear because you need n shares plus n shares of the MAC, which is good, but does it really work? Well, not in a straightforward way because notice that in the bedosa, the keys for the MACs were privately held. Well, now we have one big master key for all secrets. So as soon as we reconstruct, we can have problems, meaning that at every multiplication in the bedosa they reconstructed, they needed the key for the MACs while yeah, if you reveal alpha in our case, you can forge every MAC, which is not really that secure, so you can take this online phase as they have. So, well, the solution we came up with was the following. We compute everything insecurely until the opening phase. We let players commit to their MACs, open the master key, and then check the MACs. And since the opening is after the commitment of the MACs, adversaries cannot really cheat. So this is the solution, and let's see how it performs. So, as I said, you have an improvement on the preprocessed data needed, and we also have an improvement on the complexity of the protocol, meaning this is really what matters instead of this. And practically, we also have a very nice improvement. Basically, two orders of magnitude. And we also have a theorem stating that our online phase is essentially optimal in your favorite measure. Okay, let's move to the preprocessing. So, yeah, so what is the target of the preprocessing? It is to generate these multiplicative triples. So the high-level idea is we want to generate random value A and B, secret share them, encrypt the shares, and from those encryptions, compute an encryption of the product of the random values. And after that, we want to distribute shares of the product. So there are some problems. So the first problem, this one, is that an adversary could perhaps not distribute ciphertext where he knows the plaintexts. And the second problem is, well, how can you compute an encryption of this product given shares of the summands? And so in the Bedouza, they were using zero-knowledge proofs for both problems while we were thinking that maybe for the second problem, so computing C, we can have a better trick. And we were thinking, well, why don't we basically embed this property in the encryption scheme? So the problem is the following. We have fresh encryption of shares, and we want to compute an encryption of the sum of the shares, and an encryption of basically a product of sums. So this is what we want. We want to have a very nice encryption scheme where computing the sum is, okay, an encryption of the sum is the same as summing encryption, and computing a product of encryption is the same as multiplying encryptions. So this might look like fully homomorphic encryption, but it's not because we just need one multiplication on fresh data. So what we came out was the following. An encryption scheme which is sum-automomorphic, meaning you can compute unencrypted data, but the computation is restricted to a certain set of functions. Basically, circuits of multiplicative depth one, or polynomials of degree two if you prefer. And okay, so what we did was the following. We took a very nice encryption scheme by Brokesky by Kutanathan, which is based on Ringelwe, and we tweaked it a bit. So we wanted to have precisely the property I just said. So computation on encrypted data, meaning just circuits of multiplicative depth one, and we also needed a distributed encryption, and since we were playing with it, we decided also to make it SIMD friendly, meaning that it handles more plain text per ciphertext. And yeah, so how does this perform? Well, this performs very well too. We have one minor problem, because we lose a bit of generality in the encryption. So in the bedosa, they allow semi-homomorphic encryption, which is a different concept that's than sum-automomorphic encryption. It's more broader than our. On the other hand, we get rid of their most expensive zero-knowledge protocol. It's really zero, the cost, because it's not existent in our case. And the offline benchmark is pretty cool. We have a speed-off of what? Three orders of magnitude, something like that. Yeah, so to summarize, our speeds protocol is an MPC protocol secured against active adversaries corrupting a dishonest majority, and we decided to build it in this pre-processing model. Our online phase is linear in the amount of data needed. It's essentially linear also in the communication complexity, and these two properties are essentially optimal for these kind of protocols in the pre-processing model. And our pre-processing is also very nice, meaning that we make a rational use of semi-homomorphic encryption. We need fewer zero-knowledge protocols if we compare to the bedosa. And as you saw, it's very practical. Let me just go back. So this value is, I think, very nice compared to this. So, okay, if you're curious, you just go into this website and you can read the e-print version of it. And so that's all I wanted to say. Thanks. Thank you.