 So the next talk is a nearly linear unconditionally secure MPC with dishonest minority by Elie Ben-Sasson, Serge Fairlostowski, and Serge will give the talk. Thank you. Indeed, this is joint work with Elie Ben-Sasson and Raphael Ostrovsky. So we've already heard about multiparty computation, we have a group of players, everyone has a private input. They want to compute some function on these inputs so that every player learns the right function value, but all the private inputs remain private. This should hold even if there's an adversary that corrupts up to T of these players. Now the classical possibility results from the late 80s tell us this is possible. This is possible in different settings. It's possible in the computational and the unconditional setting if T is smaller than N over 2 and it is possible with perfect security if T is smaller than N over 3. Note that I'm ignoring here the case of computational security and the dishonest majority because there you cannot really get full robustness. Now once that we have these very nice possibility results, it's natural to ask what is the complexity of multiparty computing functions in the different settings. And indeed a lot of work has been dedicated in reducing the complexity by the way one means complexity, I mean communication complexity, how many bits do the players have to exchange in order to securely compute a function. So a lot of work has been dedicated to that question and this table here summarizes the state of the art for the different settings. So the complexity here is expressed as the amortized communication complexity per multiplication. So how many bits do the players have to exchange per multiplication in the circuit representation of the function assuming that the circuit is big enough. And you can see in this table that for the computational and the perfect setting multiparty computation can be done with neo-linear communication complexity which is also what we can do in the much simpler passive case only in the unconditional setting with a dishonest minority. The best known scheme requires n squared times k bits of communication per multiplication gate where k is the security parameter. So our result is to show that actually also in the unconditional setting can do with essentially linear communication complexity. So you see we have this additional plus k here but this can actually be further reduced and probably can be removed altogether. So our new protocol makes use of a whole range of known tricks and techniques, make use of show me a secret sharing scheme, beaver circuit randomization that also Valerio briefly mentioned, make use of the dispute control framework by Berliova and here to make use of a linear type passively secure multiplication protocol by Dom Gordon-Dielsen and so on. And there's a lot of cumbersome fine tuning involved but crucially our protocol relies on two new techniques. So one of them is a batch verification scheme for a multiplication triples, it's a scheme that allows to verify a large list of shared multiplication triples in one go meaning with better efficiency than verifying them one by one and I want to point out that a similar technique was concurrently independently introduced by Dom Gordon-Dielsen in a paper that was presented last week at the ICITS conference. And the second technique is what I call here an efficient mini-multiparty computation for computing authentication tags and what exactly this is you're going to learn in the remainder of this presentation. So if you do a multi-party computation that at some point to get to the point where players have to reconstruct the shared secret but some of the shares are incorrect. And it turns out that in the setting that I consider here where t is smaller just below n over 2, this is actually not possible without additional redundancy on the shares. It was shown by Eurebin and Benog in 89 how to add additional redundancy to enable the reconstruction of a shared secret in the presence of full t-shares. Essentially this is done by pairwise authenticating the shares. So if we append to every share a list of authentication tags and the list of authentication keys or specifically for every pair of shares we append an authentication tag to the share si and the corresponding verification key to the share sk then this is going to work out. So you can think of this tag here as a signature on the share si that can be verified by this tag here except that this is non-conditionally secure signature and I mean actually it's I mean the tags are computed with this simple formula here. I mean it's sort of well-known if you work things out and you see that if we have this additional redundancy on the shares then the reconstruction of a shared secret in the presence of false is possible. If you want to make use of this approach then we run into two problems. First is that this additional redundancy is going to blow up the complexity. And the second problem is the question who computes these tags. I have to argue that if you have this additional redundancy on the shares then the reconstruction of a secret in the presence of false shares is possible but who produces this redundancy. I'm going to say more about that in a couple of minutes. First I want to briefly say how we address problem one. Actually I don't want to say too much about it. This can be solved with a standard batching and reusability techniques. So essentially what we do instead of authenticating each share of player PI individually we authenticate a whole batch of shares in one go and we observe the part of the verification keep can be reused so that in the end we only need a small number of keys and tags to authenticate a large number of shares so that in the end the efficiency loss due to dealing with the tags and the keys becomes negligible compared to the rest. By the way from now on I'm going to focus on one pair of players PI, P, K. Consider fixed pair players PI, P, K and I'm not going to write these double indices to the keys on the tags anymore. But I have to keep in mind that this in the end has to happen for all pairs of players. So more interesting is problem number two, who computes this tag? And the point is that the person, the party that performs this computation that computes this tag needs to know the share here, player PI's share and also needs to know the key alpha beta that is held by the player P, K. Now if you think about it, it's not going to be the player P, K who can perform this computation because P, K is not supposed to know the share of player PI during the sharing phase. Also it cannot be the player PI who computes this tag because player PI is not supposed to know the verification key. If he knows the verification key then it's easy for him to forge authentication tags, right? You might think that the dealer, the guy that performs, that produces these shares could also perform this computation, but also here if the dealer is dishonest and he knows the verification key then the whole authentication business is useless. Now the standard way to deal with this issue, the way all previous papers dealt with this issue is by not authenticating the shares, but by doing a second level of sharing and then authenticating the sub shares. So as sharing is done as follows, dealer shares secret, every player takes his share, reshares his share, and that player then computes the tags for the resulting sub shares. And if you work things out then you see that this does the job. The problem for us is that as soon as we start sharing shares, we get the quadratic number of sub shares so we get at least quadratic communication complexity, we want to do better. So this is one of the reasons why in previous work they didn't get below quadratic communication complexity, we want to do better. So we need to deal with this issue in a different way. So let's lean back for a few seconds and look again. What is the problem that we want to solve? We have a player PI that holds some private data, his share. We have another player PK that also holds some private data, his key. And we want now that player PI learns this function of this private data, but he doesn't learn anything beyond that. And then the other player should learn nothing at all. This is nothing else than an example multi-party computation problem, right? So in principle, we could solve this just by doing a multi-party computation. I mean this would work in principle. But if you want to improve efficiency, this seems like a crazy idea. How can we improve the efficiency of multi-party computation by using multi-party computation as a sub-routine? And I mean if you look a bit closer, every multi-party computation scheme starts by sharing the private inputs. One of the private inputs here is the share. So if we start sharing shares, we're back to having quadratic communication complexity. So this appears hopeless. I mean there's still some good news which I want to point out. Namely, the circuit to be multi-party compute is extremely simple, right? Also because of all this batching and reusability of the keys, which I haven't explained in that detail, you just have to believe me. Don't really have to worry about the other inputs, the alpha and beta and the efficiency we get by sharing those. Because I mean I've mentioned that in the end we only have to deal with a limited number of tags and keys for a large number of shares. And also because we make use of the dispute control framework, we only need passive security for this multi-party computation of the tag. We also need a way to verify the correctness of the tag once you've computed it in an optimistic way. What this can be done with a standard cut and choose technique. But still we're stuck with this problem here. That one of the inputs to the multi-party computation is a share. To do a multi-party computation we need shares of that share, but we cannot afford to share this share. Now comes sort of the cool trick, how we avoid this problem or how we overcome this problem. We don't share the share. Instead, we use the remaining shares of the secret of which the share si is a share as shares of the share si. Now I know that sounds very complicated. It's hard to say and it's even harder to understand. But that's why I have this picture here, so let me explain it once more. So the situation is that we have a secret here which is shared. We have this share si for which we want to multi-party compute an authentication tag. In order to do that, we need shares of this share, but we cannot afford to share that share. Now the crucial observation is that the remaining shares of the secret s have the following property. Any t of these shares not only give no information on the secret s, they also give no information on the share si. And also any t plus one of the remaining shares, not only uniquely determine the secret, they also uniquely determine the share si. So these remaining shares of the secret s, I can understand them and I can use them as shares of my share si. And they're already there. I mean, I don't have to communicate anything. So in some sense I'm making use of this symmetry. You show me a secret sharing scheme that it doesn't really matter in which slot I put the secret and in which slots I get the shares. So with this idea of the actual multi-party computation scheme for computing these tags, it's then going to look as follows. So if we have sharing of a secret s, and here is this share for which we want to multi-party compute the authentication tag, and we're going to use these remaining shares of the secret s as shares of the share si. Okay, so then what's going to happen is that the player PK who holds the keys, holds alpha and bit are the verification keys. First, he shares alpha using the same variant of Shamir's secret sharing scheme where the secret is at the evaluation at the point i. So I mean specifically chooses a random sharing polynomial that evaluates to alpha at the point i. Also it has to vanish at the point zero and the other evaluations are the shares that are then handed out to the players. Note that here, player i, he doesn't get a share of alpha because his slot is already taken over by the secret, so to speak. Player PK also shares the other part of the key beta in exactly the same way, except that he uses a sharing polynomial of degree 2t. But also the secret is at the evaluation point i and the polynomial has to vanish at the point zero. And then the players perform the computation of the tag on their shares and send the resulting share of the tag back to player pi. Player pi can then reconstruct this polynomial, which has the property, it's easy to verify. I mean, by performing this computation, the players essentially perform the computation on the polynomial. So it's easy to verify that the polynomial that the player pi can reconstructs down here at the point i evaluates to the correct tag for his share. So he gets the tag for his share and nothing beyond that. Note that, I mean the way I explain it here, again it looks like player pk has to share alpha and beta every time when you want to compute a tag for a share here, but again this is taken care of by doing batching and reusability. So actually these sharings only need to be done once and for all in order to authenticate a large number of shares. There are a couple of subtleties that I'm ignoring here. There's one subtlety though which I'd like to point out, which is the issue of fixing these sharing polynomials to 0 at the point 0, which we actually have to do so that the player pi has sufficient information down here in order to reconstruct these polynomials here. But this has the following subtle effect. If the adversary corrupts, if the adversary does not corrupt, player pi here, but he corrupts t of the other players here, then he gets to see t shares of alpha. Plus, he knows that the sharing polynomial evaluates to 0 at the point 0. So he knows t plus 1 evaluations of the polynomial, therefore he actually knows the secret alpha. But this only happens if the adversary corrupts, sorry, this only happens if the adversary does not corrupt player pi. And in that case it's useless for him to know the verification key alpha. Doesn't help him, it doesn't help the adversary to know the verification key that is used to verify the correct share of an honest player. It only helps him to know the verification key that is used to verify p8 player pi's share if he corrupts player pi. But if he corrupts player pi, because pi doesn't get a share here, he only gets to see t minus 1 shares plus the evaluation at 0. Then he only knows t evaluations of the polynomial, and then he has no information on the key alpha. So this works out nicely. Well, I'm doing well in time because I'm at the end of my presentation, essentially, conclusion to draw is there exists an unconditional secure multi-party computation with linear complexity also in this setting. Yeah, unconditional security and the dishonest minority. Another conclusion to draw from this talk is that in some cases, and I bet you didn't believe that before my presentation, but in some cases, multi-party computationally actually improves the efficiency. And you have some open problems. Let me just single out the very last one, which is about generalizing these results to the non-threshold adversary case. Because yeah, our technique relies on the symmetry property of some secret sharing scheme. And so it's not really clear what we can do in case we use another linear secret sharing scheme, which probably doesn't have such a nice symmetry property. And yeah, that's about what I wanted to tell you. So thanks a lot for your attention.