>> Seny Kamara: Okay. So the last session is going to be on asynchronous and broadcast-efficient MPC.
And we have Juan Garay from Yahoo Labs telling us about broadcast and round efficient MPC.
>> Juan Garay: So hello everybody. Thanks for hanging out until the last minute. So I’m going to talk
about broadcast and round efficient secure multiparty computation. This is joint work with Clint Givens,
Rafail Ostrovsky and Pavel Raykov, who is, just found out is Rayana’s lost brother. Where is she? She
left. That’s a joke. So by the way, Pavel is sitting right here. He’s ready to assist and you know, answer
all your questions so feel free to ask.
So secure multiparty computation in case you haven’t heard, [indiscernible] a bunch of [indiscernible]
trying to compute a function and here is the ideal world where the trusted party computed the
computation they want to do and we are trying to have a protocol that emulates that ideal process.
Okay?
So basic introduction and of course there are malicious participants and here we will be talking about
the multiparty setting introduced by GMW back in ’87 where we have n players which corrupted and
they tried to compute a public function and there is a correctness requirement and a privacy
requirement. Okay so it’s a multiparty serving [indiscernible] to secure a two party computation which
introduce by Yahoo which we heard a couple of times already in this workshop. That’s another joke.
In fact the original formations for the computational secure setting. Okay? Now they mention
broadcast in the title. Broadcast in fact is another type of functionality but also important building block
for MPC. And oh by the way this is a soccer inspired talk so you get to see the… can you guys tell me
where this comes from?
>>: [indiscernible]
>> Juan Garay: This is South African. So there is a basis source right? So if you send value then
everybody gets the value and everybody knows so everybody else got the same value and so forth, for
some basic functionality. Of course there are corrupted participants including the sender or the dealer.
Okay? And this was formulated by PSL back in 1980. And when you try to enter this functionality using
point to point links you have these two conditions called validity and agreement, meaning that when the
source is shown [indiscernible] the value [indiscernible] delivered. Otherwise there is a consistency
condition.
So that’s about the functionality. So let’s go back to MPC and one of the model assumptions for
different settings. Here I’m going to talk about unconditionally secure MPC, meaning no cartography
and no balance in the computation power for the adversary. And it was, this was treated by BGW and
CCD in ’88 where they show that you need t the number of corrupted players less than n/3. That is a
necessary and sufficient condition. Okay?
Now what are the resources they need to perform this computation? They need secure pairwise
channels as well as the broadcast channel. But that’s just a convenience because in this setting as we
saw, you can emulate this functionality by point to point communication. Okay?
So let’s say a condition setting n number of corruptions is less than a third with [indiscernible]
participants and when you want to tolerate more corruptions up to less than half, [indiscernible]
showed that you could do it again using secure pairwise channels and a broadcast channel. Except that
in this setting it’s no longer a convenience an abstraction that you can use to make this [indiscernible]
easier. What you need is a physical resource. Okay?
Any questions for Pavel? He’s falling asleep. So let me remind you also what a protocol for MPC will do
is something that’s called the share-compute-reveal paradigm where there is a share phase where each
player commits to their inputs. Here we are talking about the multiparty setting and the [indiscernible]
setting so the usual tool for doing this is verifiable secret sharing which I come to in a minute. And then
there is a compute phase where the shared inputs are used to evaluate an arithmetic circuit and they go
gate-by-gate, level-by-level. And then there is the reveal phase where everybody has verified the
verifiable sharings of the output of the function which they distribute. And then they reconstruct this
value. Okay? So shared-compute-reveal.
Arithmetic gate, so here is a [indiscernible] in the Boolean case is the most expensive part of the MPC
protocol and typically requires interaction and the use of the broadcast channel. And Marcel explained
that there is this trick introduced by Beaver about multiplication triples where you can share random
triples say a, b such that ab = c. And then the cost of multiplication during the actual computation phase
becomes much easier. In fact, the adjusted cost of one VSS reconstruction phase. Okay? And this is
usually called pre-processing or the [indiscernible] phase of MPC. Okay? Questions?
So I mentioned VSS, verifiable secret sharing is [indiscernible] where there is a [indiscernible] two
phases. There is a share phase where the dealer distributes shares of a secret s to everybody. And then
player interact to verify that that’s a valid sharing of the secret. But we are talking about actively
malicious parties here.
And then there is the reconstruct phase where dealer, you know the players putting all their shares
together, you know they can reconstruct the secret. And there are some security conditions,
requirements for this. Whereas the commitment phase that we talk about, let’s say even if a cheating
dealer that is cheating, that there is a value that is committed to the share phase, there is a correct
condition saying that everything goes through. The privacy condition that says nothing is revealed about
the secret until the reconstruct phase. And a useful property of this scheme is called linearity which
means that once you have verified shares of different secrets, they use verifiable share of linear
combination of the secrets. And that’s convenient when you do the computation.
I’d like to remind you in this setting we’re talking about statistical security, meaning that there is a small
probability of error that protocols have to tolerate because it’s impossible to not have it. Okay?
So we were at the model assumptions. We note that in the t < n/2 case we need the broadcast channel
and this seems to be an expensive resource because you can think of for example establishing private
secure pairwise secure channels by [indiscernible]. But it’s not clear how you do that in the case of
broadcast channel especially if participants are geographically scattered short of having a trusted party
doing it.
>>: [indiscernible]
>> Juan Garay: Yes.
>>: Can I ask a clarification? Does if you use a broadcast channel does it have to have a guaranteed
delivery or?
>> Juan Garay: Yes.
>>: Guaranteed delivery. [indiscernible]
>> Juan Garay: [indiscernible] yeah. Okay. So it’s no longer a convenience. You need this resource,
you’re going to implement it you know, you might be able but it should be expensive. So the purpose of
this talk, this work, is so expensive thing, let’s try from a practical point of view let’s try to minimize its
use. And you know from intellectual point of view it’s a challenging task to try to figure out how many
times this broadcast functionality is needed when you do an MPC. Okay?
So what’s the goal? This is what I just said. We are going to try to minimize, to reduce see how low we
can get the number of broadcast rounds for this setting. And also we want to do it at the same time,
maintaining, you know making the whole computation “fast” meaning constant overall rounds. But
because like we saw before, there is a pre-processing phase okay which you would like, it’s an
[indiscernible] phase you would like to happen fast and then you open it up to the computation. You
know like linear rounds [indiscernible] scalable [indiscernible]. Okay? So we want to minimize number
of broadcasts and do it in constant rounds.
So here are some results. We show a VSS protocol. We are talking about MPC right? We are going to
start with fundamental building blocks that make MPC possible on this VSS. We show VSS protocol that
uses two broadcast rounds and constant overall number of rounds. And to our knowledge is the first is
the first linear VSS protocol with these features. Sometimes you’re going to see this notation. This
means that the VSS description has two phases. Share reconstruct. This [indiscernible] means this
happens that the sharing phase, share phase on the other reconstruct phase. And same for the number
of rounds. It’s a little bit, you know, 20 rounds and we are in the reconstruction phase. Okay?
And another important building block is that we achieve a constant round pseudosignature
construction. How many of you are familiar with pseudosignatures? Okay so talk a bit more about this
which is a cool thing if you don’t know it. We obtain that from an unconditionally secure anonymous
channel which is also known as DC-nets, networks due to Chaum in ’88. Also interesting abstraction
because again to our knowledge we couldn’t find a constant round construction to do this. And this is
going to use in a black-box manner VSS and therefore has the same broadcast complexity. All right?
And so let me start with VSS. And this is a black-box use of VSS. This is a mess in the sense that we
started building from an existing VSS protocol and see what we could, what things we really need and
try to cut them off. It’s not black-box at all because we open the protocol we try to minimize
[indiscernible] lab and so forth. So it’s a little hard to explain it. But on the cover you get some idea of
what’s going on.
So to do this VSS we need building blocks. One of them is called weak secret sharing. All verifiable
secret sharing is, is the same as VSS except that there is a weak commitment requirement in the sense
that the dealer is going to commit to a value or some bottom. This is going to be the output phase, the
output value. Okay?
And further, it can be weakened further by saying you can do this without agreement, being in doubt.
Not all the players are going to be deciding the same thing. Some of them are going to be outputting
some value in the field F. And some will say I don’t know to the bottom. Okay so that’s the difference.
We’re going to be…
>>: [indiscernible]
>> Juan Garay: Yeah. For this, it is either two outcomes. Either [indiscernible] value and then there is
the correctness privacy and the EID properties.
The other building block is called information checking, which is a signature-like functionality for the
[indiscernible] setting. Again here there are two phases. One called authenticate and one called reveal.
This was introduced by RB in ‘89. And here there are all these players where the dealer sends a value to
a distinguished player called the intermediary and a bunch of receivers. Okay? So he sends the secret
of some authentication information and then the reveal phase where the intermediary interacts with
other players and the players accept or reject the message. Okay?
So RB did it for three parties. Here I’m talking about the multiple receiver case. Okay? So there are
security requirements. Correctness everything goes well. Non-forgery means look at this guy, right, so
he’s getting the secret and some authentication information. This guy should not really, this guy is
corrupted he should not be able to cheat and make the receivers buy another value. Okay? And there is
commitment and non-privacy so you must be for it.
And what I want to point out in this slide is that we are going to be using a triple protocols to do this, to
describe this information checking protocol. You can think of ICSetup and ICValidate as being part of the
authenticated or the authenticate phase. Okay? And ICReveal when the intermediary sends a value to
everybody and the receivers accept. Okay? So I just want to remember the names of these
[indiscernible] I’ll be using.
And this is how you would typically do it for the three player case. If you have a secret, you choose a
random point over here and choose three points that are co-linear. With a secret intermediary gets
these values and the s on this value here. And the receiver gets these two values. Okay?
Then they can validate by sharing another random secret called s prime. And then perform this test. It’s
a linear computation of these things. The receiver is going to get this value, is going to check
[indiscernible] on the same line without revealing what the secret was. Okay? It’s a simple
[indiscernible] thing. The general case is going to be a polynomial degree t and so forth. This n = 3 case.
All right. So we have recently shared information checking so when we try to show you how to do this
VSS in two broadcasts, we start with a new weak secret sharing protocol in which the sender, the dealer
is going to send a polynomial but where the shares are going to be IC authenticated as we described
before. Okay?
And if we have a WSS weak secret sharing with agreement, then a reconstruction, we’re going to have
to share [indiscernible]. It is going to hold more than two shares of reconstruction preliminary
reconstruction secret. And here is the protocol. Essentially what we are going to do is this line that we
had before with this secret and here the dealer does [indiscernible] and validate using the same player
that the share goes through as an intermediary and everybody else is the receiver. Okay?
Notice that the player already got the share so there is no privacy violation. Everybody has got the
verification data so far and there’s going to be these two rounds. And this takes two broadcast rounds
because that’s what the information checking protocol takes. And then here you do a reveal. Okay and
the secret is accepted if you get, if receivers get a - t, the intermediary gets a- t, okay and those values
from all the receivers. If it doesn’t, [indiscernible] the secret goes for the bottom of the high level. It is
the WSS that uses information. Checking takes two broadcast rounds [indiscernible]. We can show that
this pair of protocols thus WSS without agreement [indiscernible] tolerates t < n/2 and it takes two
broadcasts which is the same as what information checking protocol it takes. So that’s WSS weak secret
sharing. Then we’re going to go to VSS.
>>: How many [indiscernible]?
>> Juan Garay: In this case here all of those parties are going to do some value or bottom because we
do without agreement. If this was with agreement it will require some other broadcast round.
>>: But there is some minimum number of respondents [indiscernible]?
>> Juan Garay: All of them. In there with agreement. Yeah so I don’t know. We’ll take care of this here
afterwards. But here there is disagreement right so.
>>: Do you perform any error correction in the construction phase [indiscernible]?
>> Juan Garay: No. Because I no see values but they can say whatever they want.
>>: [indiscernible]
>> Juan Garay: Weak secret sharing is a weak commitment.
>>: So it’s a weak commitment.
>> Juan Garay: And the weakness is in that you are either [indiscernible] this or a bottom for example.
I’m not going to get to pseudosignatures which is a pity, unless. Okay. So this is inspired by the original
[indiscernible] protocol except that here dealers usually share this part of t and a bunch of other
polynomials, lots of them. Now players commit to WSS but see that each player commits to WSS shares,
including the players themselves. So that’s a new trick here. Okay the receiver shares are going to act
as dealers in the WSS protocol. We do the same trick about the cut and choose type thing, you know to
verify that the sharing is proper. And then there are complaints. So they are, you know the dealer is
going to fix those complaints, if things don’t match and so forth.
So from this you can see that there are two broadcasts. We said two broadcasts from here and one
more broadcast over here. And there is a cut and choose thing in which the challenge has to be
broadcast. So there is four, four broadcast rounds in this protocol. This is what I just said before, that
every player is going to WSS, weak commit to shares.
And here are two options. The first novelty is what I just said. And the second novelty is that we are
going to make sure that this challenge is broadcast together with some other broadcast. Okay? By
doing some other trick which we call semi-commit by sending information through point-to-point wires.
Okay so the bottom line of this protocol is that after the share phase when you reveal all the good
players have green or red and [indiscernible] striped the secret. Okay so far we have like three
broadcast rounds. Now we are up going to show you one extra round by something called modercast
which comes from moderated VSS, something that KK introduced in ’06, which is a variant of VSS where
one-on-one party acts as the moderator. Okay?
In this case things happen according to the moderator being honest or not. Okay? So besides the
decision value there is a grade that is a 1 or 0. Okay so if the moderator is honest, so everybody up with
this notice that it might not be the value that the sender sent. Now if some honest party has grade 1
that everybody had the same value, but they might be further on the grade. And importantly if some
honest party has grade 1 and the source is honest the thing goes through. Okay?
So they show a way of compiling original protocol that uses broadcasting to a protocol uses this
modercast functionality in such a way that you don’t use broadcast anymore. But if one of the players
has this flag equal to 1, then broadcast happens. So the point is we make sure that one of the players is
honest. Okay. This is high level so we show you off one broadcast round by turning the three broadcast
protocol, VSS protocol we have into one where the dealer acts as a moderator for broadcast. Okay?
So we can throw away all the work that we have that in the beginning [indiscernible] by just one and
there is another one that you know is the last broadcast round. So we got it down to two. And this way
we got two broadcast VSS protocol. High level, you get ideas of what tricks we’re using. Again this
being a little work on VSS but there is thought that this is the lowest number of broadcast VSS too and
cost a number of rounds. Okay?
And Pavel and Martin [indiscernible] in fact have a one broadcast VSS protocol. Except that
[indiscernible] takes linear number of rounds. So it’s open whether you can do one broadcast and count
the number of rounds.
Okay. So in the last two minutes let me tell you what the pseudosignature contraction is about. Then
we’re going to put these building blocks together and show you how to do MPC using this round data to
broadcast.
So this contraction is basically anonymous channel, uses black-box VSS which means we’re going to use,
going to plug in the VSS that we just designed. Three minutes. So what are the differences between
pseudosignatures and signatures? I guess the main difference is that there is no single verification key
that all the parties have. Different parties have different keys. They have lots of them. They are secret.
They’re not public as verification keys. They need a physical broadcast setup so that sounds familiar.
And another feature or bug is that they have limited transferability. Many have [indiscernible]
signatures you can sign and you know the receiver can transfer it to another receiver so far. This is
bounded because when a signature is transferred it degrades. Okay at some point you don’t know
what’s going on anymore.
Now why are these things important is because when you have them then you can implement broadcast
channel. You can emulate them with [indiscernible] and protocol that works for every type of
corruptions or at least the majority of honest parties. By this work in the computational setting, oops.
How did that happen? Okay so just plug in the pseudosignatures where computational signatures are
used… sorry guys I have to go to a meeting now. And therefore there is no more physical broadcast
needed. So the only physical broadcast work you need is for the setup of pseudosignatures.
Now this is based on sender-anonymous channel, aka DC-nets. You have a bunch of messages by a
bunch of players. You have a receiver get into this box and then the messages are shuffled. So the ref
here is looking at the card, red carding somebody, but he’s trying to figure out who sent what message.
Okay?
No time for properties, but I have a bunch of properties. And the most important one is the anonymity
that says even a cheating receiver can’t figure out who sent what message. Okay?
And the construction idea that we have is something that is called throwing darts. One possible
construction is [indiscernible] permutations. And then as you pick a long enough vector and you place a
bunch of your messages at random, all players do it. Okay? So of course malicious players can do where
one can fill up the vector. Of course it could be commissions. You know, people choosing the same
slots. So you have to prove all that, you know prove [indiscernible]. And then the accepted vector is the
sum of all the participants of vectors. Okay? And this gets us to the random. So those messages I call k
with foresight because those could not be the keys for pseudosignature construction.
Now how this works is that the players, the receivers all send to themselves, send the keys, the
verification keys to the signer and keep a cover for themselves. And you do it a bunch of times and then
the message is assigned by the signer by applying authentication code to the message with all the keys
that p got. Okay?
So when the receiver gets that you know it has to verify all the components [indiscernible] or not. There
should be in each block there should be only signature for each receiver. Okay? And a little bit of
thinking will tell you that the first receiver will be able to verify all of them but the second receiver might
not, so it has to be more tolerant. So the verification procedure has to do with where you are in these
transfers.
I’m almost there. Okay so this protocol implements anonymous channel for the setting where we are,
uses black-box VSS. The broadcast complexity is the same as the VSS protocol. And there’s a bunch of
related work on anonymous channels but the good thing about this is it seems to be the first, not just
information [indiscernible] but also cryptographic construction [indiscernible] constant round.
[indiscernible] Okay?
Now we have these two components of VSS. We have pseudosignatures. So how do we come up with a
protocol for MPC? So the beginning part is involving the [indiscernible] protocol to generate the
pseudosignatures for the rest of the computation. In this generation they use VSS. So they use two
broadcast channels. And from now on they start signing messages. They emulate the broadcast
implication by a protocol that emulates broadcast. And they use protocol for doing this is a protocol by
[indiscernible] which is constant-round and is randomized. And here all the [indiscernible] broadcasts
use the kind the competition takes [indiscernible] proportional to the depth of the circuit.
To summarize then, we talk about broadcast sufficient VSS and constant overall rounds. And I show you
a constant-round pseudosignature construction. The first part was in ICITS 13, not 14 and it’s in the
ePrint Archive and its unconditional secure channel will put it in the ePrint soon. Thanks. [applause]
And check this out. My next version of this is going to be you know how like the metrics always
[indiscernible]
>> Seny Kamara: Thank Juan again. [applause] Our next speaker is Aniket Kate from Saarland
University and he is going to be telling us about asynchronous MPC with t < n/2 corruptions using nonequivocation.
>> Aniket Kate: So hello everybody. Welcome to my talk on asynchronous MPC and I’m going to use
something called non-equivocation to do that. So in the last talk we got nice introduction to what I am
going to present so many of the things you will find helpful. The key two differences we are no longer in
the information security setting. We are in cryptography setting and so that’s one thing down, but
[indiscernible] setting now we are considering asynchronous setting and that’s what we will be looking
here. This is joint work with Ashish Choudhury and my collaborators from Saarland University, Michael
Backes and Fabian Bendun.
All right. So a brief roadmap what we are going to see here. I’ll first talking, start say what is
asynchronous communication? And this is the first talk on this topic over here so I’ll give a brief
introduction for somebody who is new here. I’m pretty sure half of you already know it, but. Then I will
say what exactly we are doing. How, what are we achieving? What can be utility of such a thing in our
contribution? Then the important component that we are using from [indiscernible] community that we
borrow. Non-equivocation I am going to explain that out. It will be followed by giving a really brief
overview of our construction for MPC and as with the previous talk we even for us [indiscernible] is an
important [indiscernible] so I will present our construction for that and the important protocol that we
use for MPC.
All right. To start with asynchronous communication setting. So as I am showing in this picture it’s all
about whether you are supposed to, if you are expecting a message from somebody and it just, the
message is not reaching you and you are confused if this guy is slow or he is crashed, the machine for
this person crashed or what. So that’s the basic setting.
So what differences happen in such asynchronous communication setting is that most of the
[indiscernible] that we saw in our discussions they have this bounded synchronous communication. And
so you have rounds. They are defined properly. You know this exact time period. And then the idea
that they know somebody is supposed to send a message in that round. They send the message and by
the end of round those messages are received by all the respective parties. Okay? It may be possible
that somebody don’t send you message but then you know that this guy either did not send me the
message on purpose or that party is crashed. So I’m showing this in this particular example where Alice
is expecting message from Charles and she sees that oh, I did not get message from Charles. So Charles
is crashed.
However, as I mentioned already, in asynchronous setting that’s not the case. We do not have such
exactly defined time rounds. So how can Alice be sure that whether Charles is crashed or slow? And the
reason to do that, the reason why we go for such model is there can be delays which are unexpected
and which can all be defining types of fraud in that work that may not only happen because of our
internet delay but just at the process level that the program that we are running sometimes it delays.
There are different other programs running in systems and they provide delays which we are not
accounting for. So that’s why asynchronous model provides an alternative where you no longer rely on
such time bounds around to do your protocol but rather you just more rely on the… some parties can be
slow but eventually the things will happen in time and we will continue. So that’s my model for
asynchronous communication. Any questions? Good.
So again just to give, make the model clear we are in the message box system, so all parties are
connected to each other by pairwise channels. Okay? And as I already mentioned in such asynchronous
channel message can be arbitrarily delayed or reordered. Anything can happen. However the
assumption there is that the messages are eventually delivered. So this is a [indiscernible]
determination. In some asynchronous setting we are, so take the second assumption out, but for us we
are going to assume that every message from an honest party will be eventually delivered to another
honest party. Okay?
So in such a setting for communication the adversary that we assume for our MPC is called active
adversary. So it’s like the [indiscernible] adversary he can compromise t parties for privacy and so they
can be a sort of malicious t’s. Okay?
As covered in the first talk of this workshop there is always good to consider the protocol in honest but
curious setting. So I’ll compare that in the asynchronous setting at the crash adversary. So crash
adversary is the guy who’s not going to do any bad things, but some of the processes may crash and
don’t send some messages or may omit some message. So by crash I also mean omission if somebody
who is more of [indiscernible]. So we consider also another the fact is there in more from cryptography
point of view is that we call such an adversary honest but curious. So it may be the case that the
machines don’t crash but those t parties can be honest but curious here.
>>: So by crash you mean one can crash at any moment?
>> Aniket Kate: No. No. So in asynchronous setting we view this omission that it may happen that some
messages are sent but some are not. And for the other party let’s say it will be difficult to know whether
it is crashed or just slow.
Okay. So as you can see we are making many things lose here and that had its repercussions. So when
we start looking at various parameters that we come across in various presentations things change. For
example if we take the broadcast channel that we talked about in the previous talk. So if we assume a
different broadcast channel in synchrony and with signature we can get this done for any number of
malicious parties so as long as n > t, we can get this. However in asynchronous setting even if we
assume signatures don’t assume we can do better than 3t + 1. We require this three times more. I
mean we can only manage one-third of malicious parties in such a setting.
For something which we are aware of now for verifiable secret sharing, it’s other way around. In the
synchronous setting we can go for 2t +1. However in asynchronous setting we again have been bound
for 3t + 1. Same applies for MPC. If we go to this fully information security setting then even the round
can go to 4t + 1 if you want the perfect guarantees. So indeed it takes more efforts in terms of the
resiliency bound at least for asynchronous setting.
And the same thing applies for the many of the primitives that use, get used or they have their own
applications in distributive setting for Byzantine agreement, state machine replication and many other
primitives. Sorry?
>>: [indiscernible]
>> Aniket Kate: Yeah. So yeah so for most of the talk I’ve been asked to keep these active. When I
[indiscernible] I should mention that they are crashed. Yeah. Thanks for pointing out.
Okay so now shifting to a particular problem of MPC and what happens for the MPC protocol in
asynchronous setting. And I’m sticking at the mention for the computational MPC here. Okay?
So there have been some work mostly by Hirt and Nielsen at ETH and [indiscernible] and with many of
these others and the best protocol so far has with 3t + 1 has communication complexity of n2k where
the k is security parameter because we are in the computational setting. And this is for [indiscernible]
okay? For my [indiscernible] date.
So the main interesting thing to look at here is that maybe communication complexity is important
parameter and so is the resilience. And as it turns out in distributed systems they give importance for
this resilience parameter for [indiscernible] asynchronous system. Google [indiscernible] doesn’t insert
user asynchronous algorithm for application. They use Paxis. And they go for [indiscernible] but they
still use the crash [indiscernible] everything is in our domain and why should we go for this fully active
adversary setting? But if the protocol are available for resiliency bound it may be possible that we can
motivate the use of active security protocol. And that’s the motivation.
In that direction, something has been done even for the asynchronous computation at MPC where they
showed that if we do one synchronous communication round, so this is work by Beerliova-Trubiniova,
Hirt and Nielsen from PODC 2010, where they showed that [indiscernible] one synchronous channel
then we can do MPC for 2t + 1. Their protocol required n4k some optimization it can be reduced by
maybe a single factor. But [indiscernible] protocol required. There was more possibilities with it.
But they still have this functional asynchronous that required one synchronous round. And the question
is can we avoid this? The important thing that I like to point out is [indiscernible] make in the
computational setting two assumptions. One is the threshold homomorphic encryption and threshold
signature. If it’s assumed that before the protocol start, there is a homomorphic encryption key like
[indiscernible] encryption where it is a threshold, the decryption key [indiscernible] distributed among
parties. Okay? So that anybody can encrypt and the whole group can decrypt that. And similarly there
is a threshold signature in the sense that people can sign and then that can be combined to generate a
signature. And as you know both of these are generally used to get, reduce the communication
complexity.
So these are the assumptions that are used. I especially pointed out the homomorphic encryption
because at least me I don’t find that to be really a great assumption because for signatures we can get
schemes in deluxe setting. However for threshold homomorphic encryption we generally [indiscernible]
and how to get [indiscernible] in a completely secure fashion. I find it to be difficult to implement that
assumption in their life. If we are to get this done without any trusted parties, so generally I’m not a big
fan of [indiscernible].
So with that now we move to what we did for this [indiscernible]. So the main thing is we find that
synchrony is not necessary if we want to improve the resilience of asynchronous multiparty
computation. We found that something which have been developed in the systems community called
non-equivocation can indeed be helpful for this purpose. In particular the protocol that we present had
just on this measure the requirement it’s a [indiscernible] communication n2k. And we do not require
threshold homomorphic encryption. We only require threshold signatures. The threshold signatures
also required to get this copper if we want [indiscernible] we just need signature encryptions or
signature and additive homomorphic encryption. We do not want any threshold assumption if, so that
just to get the complexity in check. Okay? And the purpose here is to find out asynchronous VSS
protocol in the computational setting which works for n > 2t + 1 and has complexity of n2k which is the
first such protocol to get it done.
Okay. So next I have been using this word non-equivocation and so let’s start [indiscernible] this nonequivocation [indiscernible]. And we started this in work which I will be using more in talk. It was a
paper [indiscernible].
Okay. So generally in this gap which we saw in the active setting [indiscernible] or the crash setting and
the Byzantine setting either so visible in the distributed systems [indiscernible]. And what have we seen
that for protocol there when we have only semi-honest plus and/or crash adversary we can get things
done for honest majority, but when we go to the Byzantine setting or active adversary setting we
require 3t + 1 or sometimes even more than that.
And it’s interesting to see why we get such a bound. And it goes back to the old, one of the really first
[indiscernible] we talk about why we had this 2t + 1 bounce for most of the schemes such as elaborate
broadcast agreement to prove which is typical Byzantine agreement problem where there is a general
who is sending attack and retreat messages to different generals and they don’t know if they got the
same instruction to whether to attack on the fort or to retreat. So as I show in this particular diagram
here there is Charles and that sends to Bob retreat and to Alice attack and if this link between Bob and
Alice is slow they will not be able to convey each other in time that the message reaching them was
conflicting and they better go to the default value. And to solve this problem we have to introduce the
[indiscernible] because Charles malicious. So to solve this problem we require four players here. And
that was the, so this will prove that this is not possible for 2t + 1 and that says that we have to go for 3t
+ 1.
So that’s the reason and we can call this behavior by Charles as pre-verification or equivocation that
Charles is sending conflicting messages to different parties in the system. And the question is what if
this is not possible. And that’s the concept of non-equivocation.
So non-equivocation it’s not possible for Charles to send conflicting message. Charles can still send the
wrong messages. They may not be consistent with the rest of the protocol. But whatever you send is
consistent across all the parties. So it’s not that I send x to somebody and x prime to somebody else. If I
send x I send x to everybody. But not just, but not x prime. So that’s the concept. It was introduced by
some guys from Berkley. It’s called Attested Append-Only Memory. So they implement that with some
kind of trusted hardware so you require the hardware which makes sure that it’s a log where you can
only attest and prove in the end and it will be append-only log so you can keep appending entries to this
log but you cannot remove entries from the log. And such a log is sufficient to implement or make sure
that Charles cannot [indiscernible] and that can be used to solve the problem of the [indiscernible] 2t +1
to just reach the honest majority. Okay?
>>: [indiscernible]
>> Aniket Kate: Yeah. So I’ll come to that. That will become clear on the next slide. But it’s yeah a
really good question. And what has been done is some guys from Microsoft Research they found that
we don’t need this, because our assumption it is possible to implement this just with a trusted counter.
So what you need in your [indiscernible] is just a counter and a signature [indiscernible] and that can be
used to implement such a log or many such primitives to get the non-equivocation.
So going a bit formally what is meant by non-equivocation is that first of all equivocating means a party
P equivocates if it sends conflicting messages to different parties when it is supposed to send the same
messages. This can be also applied to not same message but rather related messages. But for simplicity
let’s assume that for us it’s said that a party is supposed to send the same message but it does not.
That’s the equivocation.
Okay. So for example here to make this have any meaning to this we have to first associate a key to this
message. So we assume that the real message that is sent had a key associated with it. And by
equivocation we mean that it’s possible for somebody to send different messages for the same key. And
how we design this key depend upon the protocol step. We can take the complete protocol and make it
step [indiscernible]. And then the key those protocol steps in a liner matter define the keys for the
protocol and that can be extended for the instance of the protocol. So that’s the idea.
Okay. So just a bit formally thing here that for an id k in natural number series m is an arbitrary message
and we say that non-equivocation allows validation of a pair k, m so a key in message pair from a party P
such that if I receive a message from party I am pretty sure that all other parties will also. If they get the
message they will get the same message.
>>: [indiscernible]
>> Aniket Kate: Yeah. So there you are. So it’s, maybe you can, let’s look at this [indiscernible]
broadcast. It has come in the [indiscernible] situation. So what is non-equivocation actually
[indiscernible] that in more distributed [indiscernible] safety is guaranteed but not liveness. So if you
get the messages then they will be the same. But it is possible [indiscernible] it is possible that the
adversary party generates your message but send only to one party but not to other.
>>: [indiscernible]
>> Aniket Kate: Yeah. So we worked on that. So in synchronous system it still bit weaker. It’s weaker
than signatures for sure. So in synchronous system we know that to implement, to use this to
implement broadcast will require 2t + 1. And that comes from some already there is, yeah but, it’s close
but it’s not still perfect. Because still Alice is not getting message.
>>: [indiscernible]
>> Aniket Kate: Yeah but to still get everything working, I mean, you are seeing this system in t parties.
For, to look at that 2t + 1 is a required [indiscernible] four parties and then see what happens in those
situations. I will be more than happy to talk to you about that. But yeah, it’s an interesting observation.
Okay. So that’s the thing. However what we followed unlike those papers [indiscernible] afterwards,
non-equivocation by itself is not really sufficient to get the guarantee that you want. This liveness
comes in [indiscernible] a lot. And in particular we saw that in asynchronous setting tolerating active
fault, non-equivocation alone does not help in reducing the number of processes. What we observe
that they [indiscernible] are use signatures for the non-equivocation. And that was [indiscernible]
property to get any, to do anything better. So that all the [indiscernible] signature themselves are not
good enough, [indiscernible] is not good enough. But when we combine them we did get basic that had
been observed by those people [indiscernible].
So what is this transferability or use of signature? What happens there? I mean as you pointed out in
your thing that say look at this situation. So here Charles has sent this message k, msg to Bob but Alice
did not receive the message from Charles. However in such a system Bob can verify the message and
then forward if [indiscernible] signature [indiscernible] non-equivocation of the transferability property
that can be sent to [indiscernible] Alice can get the message and verify it. And then [indiscernible] this is
a message that was sent by Charles although I did not receive it from Charles [indiscernible]. Okay? So
that’s the transferability of non-equivocation which becomes important for it to become any help.
So I would like to point here a very small point about signatures. Signatures also [indiscernible] here
because in signatures in the basic digital signature it is possible for Charles to create two different
signatures and send that to Bob and Alice separately. So if the channel between Bob and Alice is slow
then they are going to terminate the protocol without listening to each other and so their outputs will
be wrong and different. So just to give motivation.
All right. So what we observe is that just not in [indiscernible] protocol [indiscernible] but it’s possible to
prorate a generic translation there. So if we take any crash fault-tolerant protocol we are transferable
non-equivocation and we get a protocol which is active fault-tolerant [indiscernible].
So for an interesting thing to see is that replication bound does not change and so are the number of
communication steps. It’s just that we have to add a wrapper which take every message, the key
associated with it [indiscernible] non-evocation signature and go to the setting and now you can solve
the [indiscernible]. You can [indiscernible]. Yeah?
>>: [indiscernible]
>> Aniket Kate: So you have a crash fault-tolerant protocol that will have its own bound in terms of d
and that just remains there. So nothing changes in terms of that. So that’s what I mean by replication
factor. Okay?
However, what we observe and what becomes the form of the discussion that I want to get into now is
that such a translation is not easy when we go to MPC and VSS protocol which that we are
[indiscernible] in the cryptography [indiscernible]. This will follow protocol like reliable broadcast or
Byzantine agreement but when you have properties such as important property of privacy or secrecy
the way we define it, then such a thing does not work because for such a protocol to have privacy
maybe the crash protocol required more primitives and [indiscernible] we have to introduce more
cryptography primitives as we see now.
Okay and that moves takes us to this employing non-equivocation to the asynchronous MPC. So we
already looked into this a bit in the previous talk that here we are doing asynchronous MPC, we are in
arithmetic circuits and we are doing secret sharing manner. The reason we are doing secret sharing
manner is because of the way we have to use threshold or more secret encryption set of which actually I
am not a big fan of.
So what happens in asynchronous setting in the input phase there are parties that have their input and
they use VSS to actually share it. In some protocols other than that we can have threshold encrypted
values. I’m going to show this in the square bracket x to show that generally a symbol that is used for
either threshold encrypted or the secret sharing [indiscernible]. Okay good.
And then we have computation phase where additions are local because generally such [indiscernible]
schemes have linearity property. However multiplication views [indiscernible] which now come, which
you heard quite a lot in this talk or in this seminar quite a lot.
And then once you look at all these additions and multiplication one by one then you complete the
whole protocol, you take your final output and you [indiscernible] to the party who is supposed to get
output. That is more like a reconstruction for secret sharing or threshold encryption.
So that’s the [indiscernible]. As you can see here the important [indiscernible] is the how do you do
multiplication. And all of the things are quite standard and also again we are using the Beaver trick and
we are seeing [indiscernible] so probably I am not going to put lot of efforts on that here so basically
what you need for this trick to work out is a pre-shared triple of that form where you, it’s a secret share
u, a secret share v and a secret share uv such that adversary have no knowledge about this uv and u,
obviously multiplication of u. And that can then if you have this with single round of G construction and
some local computation you can generate the sharing of multiplication of two shared values x and y
here. Okay?
So for this to work out what we need as we have seen in previous talks is a pre-processing phase where
the, we need to compute this uv [indiscernible] in triple and that forms the main step which becomes
the formation of most of the MPC work is the triple generation, how we generate these triples. Okay.
I have this well supervised and what will become very shortly clear is that like in previous talk we also
have this we called this [indiscernible] but it comes with different name. That this guy who works as the
moderator and it have some special properties to it.
So I will very briefly give overview of what exactly the supervised triple generation. So as you know, we
need to generate such triples. Okay? So the main thing that happens is this is how we generate this so
we divide up the protocol in four generating such a supervised second generation that we call that is
generating one of them separately. And then using that and interaction among parties to generate this
four standard code generation. And once we generate that you can use one instance and get the final
output supervised triple generation. Okay?
But this itself required n instances of a protocol of supervised pre-multiplication where we take this v
here and every party just keep on multiplying with the random number u which is secret sharing. And
all those things internally use a protocol which we call supervised sharing which is quite close to
verifiable secret sharing. Okay? And as you can see in this diagram they are mostly one instance except
for the n instances [indiscernible]. So what is the communication [indiscernible] protocol? Probably it’s
going to increase by a linear factor when we go for the final supervised triple generation which defines
the communication complexity for the protocol. Okay?
So as I mentioned, we are now going to look at the supervised sharing. So I mentioned that this is
almost secret verifiable secret sharing except that we have this one more [indiscernible] and we clarify
in the paper in more details. It’s just a really small addition to any VSS protocol or at least our VSS
protocol.
So what is VSS? We already saw this and I’m going to briefly, very quickly go through this. So there is a
dealer with a secret and he provides shares to four parties and such that a predefined subset of t + 1 can
do the reconstruction for them. And I’m going to go over this very quickly because we talked about this.
We have properties of correctness and secrecy and we also talk about this property of commitment
where the dealer can be malicious and try to play games. Still the reconstruction should always work
out for that given set of parties. Okay?
So in asynchronous setting where we briefly look at what are being very difficult is we require 3t + 1.
And the general idea is that the n parties, we are in asynchronous setting, we cannot wait for everybody.
So we have to rely on information from n - t which is 2t +1 parties. Okay? Now for the VSS protocol
they will make sure that they have consistent sharing, that they have enough information for the
system. Out of this 2t + 1 again t can crash or can be bad parties so only t + 1 parties will be there. As
you can see, this t + 1 has enough information to help all other good parties because [indiscernible]
share, they can provide the shares for all other guys. Okay?
This does not work once we have n > 2t +1. Why? Because the steps still remain the same but the last
one only will have one guy with correct sharing. And then we [indiscernible] difficulty of what we are
trying to do. In such a setting there will be only one honest, there can be only guaranteed one honest
party who got the consistent sharing or consistent information. And how can that be sufficient? And
that takes us to very quickly going to this problem has nothing to do with active adversary. It’s a
problem which can also happen in the class setting. And because it just depends upon the asynchrony
that is getting used here.
So as we saw in the first talk in the seminar today it’s always good to look at the honest but curious
adversary. So we have to look at there for crash setting and we see that this problem is very difficult.
We have to use encryptions. So that there will be one guy who have encryption shares for everybody.
And that’s what we use so I did very simply this of some work similar to old work where the dealers
entered the shares and a vector of encrypted shares such that they were encrypted for respective
recipients. And send that to everybody. Now everybody gets these shares when they act out crash
setting okay? So [indiscernible] get directors to keep their own share. They take it and send whole
vector to everybody else. Okay?
So this is simple protocol but the complexity is n3k. And if you remember my diagram this will make the
complexity for the protocol for MPC and [indiscernible] at least or maybe even one more. So we have to
do interesting mechanics to view this complexity from n3 to n2. Okay? And that’s where the threshold
signature assumption can help.
So very quickly I’m going to [indiscernible] when we shift this protocol from class setting to active
setting, we have transferable non-equivocation, which makes sure that only one valid sharing happens.
We have to introduce zero knowledge proofs to make sure that the sharing which is happening now we
have encrypted shares and we have to make sure that they indeed make a valid secret sharing. So that’s
why for that [indiscernible] proof.
And we use threshold signature to make sure that we can reduce this complexity from n3 to n2. So
that’s very short, brief overview. We have all the protocols and they have security proofs in the paper
which I cited and you can easily find out with the title, with just the same title as the talk.
So what we see in this particular talk? We saw that very small, maybe we can call a mini trusted
hardware assumption in the form of transferable non-equivocation can be helpful for to reduce the
resilience, the resiliency bound in distributed cryptography protocols. In particular we are able to
improve the resiliency bound for MPC and VSS in the asynchronous setting.
In the process we found that it’s a bit surprising that we require encryption and zero knowledge proofs.
And in particular encryption [indiscernible] learning in the crash setting when we do not have broadcast
channels and synchrony. So we show the interesting thing on its own. And that just what we learned
but it will be interesting to add when the question comes up, in the synchronous setting just not
transferable basically non-equivocation still required 2t + 1. And so can we do [indiscernible]
combinations in the synchronous setting or in this work we went for resiliency bound. Can we use nonequivocation to reduce the complexity from n2 to O of n? Things like that they can be really interesting.
So yeah these are the things which we have seen in this talk. Thank you. [applause]
>> Seny Kamara: We are once again out of time. So we will take further questions offline and let’s
thank Aniket again. [applause] The last speaker of the workshop is Mahnush Movahedi from the
University of New Mexico. She will tell us about efficient asynchronous secure multiparty computation.
>> Mahnush Movahedi: Hello everyone and thank you for listening to me. I’m introduced before and
I’m going to talk about quorum quicken queries efficient asynchronous secure multiparty computation.
This is a joint work with Jared Saia, Valerie King and Varsha Dani and the things that I’m talking today is
from our paper in [indiscernible] 2014 which won the best paper award and I hope that you like it.
Okay. Multiparty computation as everybody know here today and talking about multiparty computation
in the setting that where we are using verifiable signature or signature best on [indiscernible] signature
and so and as Juan Garay presented is very [indiscernible]. So our model is we are in the communication
model which is pairwise private channel and we are asynchronous and adversary static unbounded and
it can control up to t number of parties which we call them bad.
Okay. In the asynchronous model then we want to perform multiparty computation in the
asynchronous model. The adversary can control the latency of the channels. And by controlling the
latency of the channel I mean that the adversary can arbitrarily delay the messages. And it cannot
delete the messages but you cannot wait for the messages anymore.
So if you want to simulate a trusted third party you cannot wait for the messages that are delayed and
it’s not asynchronous setting so you have to compute f after you receive enough inputs. And you can
only wait for n – t inputs because t inputs can be bad. And what makes a really difference is that you
have to count the number of inputs which is a challenging problem. And the other thing is that parties
cannot wait for all messages so it decrease the number of bad parties. You cannot tolerate up to and
over three any more bad parties as Aniket said unless you have some specific hardware or something.
So it decrease the number of bad parties and then everybody waits [indiscernible] and set up time
everybody waits for a message. If it receive a message then it goes to the next one. But the challenging
part as I am going to talk about first is how to count the number of inputs. As Juan Garay and Aniket
said we can have verified signature for asynchronous setting but every player has to [indiscernible] and
verifiably count each input and everybody has to count the inputs.
Okay. So first step is to count the ready inputs. Let’s look at this problem in the [indiscernible] setting
not the cryptographic setting. So there is a problem. We have a problem. N good parties with a bit
initially set to 0 want to count the number of inputs which change from 0 to 1. We introduce a new data
structure. It’s a distributed data structure that can solve this problem. We call it t-counters. And this
number of bits that it sends and receives each party is log n and its computation per party is log n and its
total latency is log n. So it’s really efficient distributive data structure.
And let me try to convince you why it’s not an easy problem to solve in this setting. Assume a really
naïve approach. Assume that there is one party here who wants to count the inputs. And these are the
parties who want to count their inputs and we want to make it in a nice and good resource efficient
manner. So if you sent the inputs up in a tree as you can see, okay. Assume that the first party sends up
in a tree its input. The second party sends it up. The third party must send it up and you can see this
guy here has to send at least n/2 number of messages. This is a lot number of messages and the
number of parties is huge.
So it’s not easy to send all the messages to count the messages. So in t-counter the test structure we
are not sending the messages to everybody. We are not sending the messages to one party to count it.
Instead we use some random nodes to send the messages and then we aggregate the messages instead
of sending to everybody. We aggregate the counts and we use this concept called randomization and
aggregation to decrease the number of messages that we have to send to everybody.
So this is our data structure. It looks weird but it’s not that much weird. There is a tree data structure.
This is the roots node and the roots node has log n number of children. And each child itself is a subtree
of different depths. So this starts from this one and then we go onto this log for counting number of
messages and that’s what’s happening in our data structure. Assume these are the guys who want to
come into their input. So they choose a random node in the first collection nodes of the subtree 1. So
this is the subtree 1. This is subtree 2 and so on.
We call these nodes collection nodes and we call these nodes adding nodes. So if these guys want to say
that okay I have a message, he choose a random node in the collection node of subtree 1 and sends his
message to random node there. So what happens next is that these guys are waiting for logistic number
of messages. For example they wait for seven number of messages. And if they receive enough number
of messages, for example seven number of messages, then they send a count message up. So they are
not sending all the messages up. They just send the count of the message up.
So what, as you can see, if this guy receive more than log number, logistic number of messages, which is
possible in randomness, it cannot send the x messages to its parents anymore. And it cannot wait to
receive a lot of number of messages because the guys behind him might be bad and they may never
send any messages. So it can just wait for half of the messages, not all the messages in that he’s
expected to receive. So what happens to the messages that he receive after them? So he sends a count
message up and for the messages that he received afterward, he chose a random node in the next
collection tree, subtree, and so he chose another random node here. And he sends a message to that
node instead of his parents. Because we don’t want to send a lot of messages to the parents. So we
choose another random node.
And that happens the same here. If this guy receives several log n messages, he sends it up, it’s only one
message. He sends only one message for every logistic number of messages. And if he receive more
than that he choose another random node in the next subtree and okay. In this manner these guys are
adding nodes. So these guys can count the number of messages he received from their children. And if
we put the threshold 7 log n so you know if this guy received two count messages it counts for 14 log n
messages. And if he sends a message to, count message to his parents, same for here. So if this guy
receives two count messages it sends one message to his parents. So as you can see here this guy here
only received logistic number of messages. And this guy here only received two messages and sends
one message. And this guy here only received logistic number of messages. And send logistic number
of messages.
Okay. Let’s try to make it more concrete for you if you don’t understand it, the data structure yet. So
these are the guys that want to send the messages. We are in the last round of the counting the inputs.
So these guys are only waiting for two more messages. Not 7 log n messages. So if the first guy sends to
the random node and send a message to this random node, and this guy is waiting for one more
messages and then this guy choose another random node so this guy is still waiting. And then this guy
sends the message to the same random node so he sends a message to his parents and it’s the same
here. He sends the message to his parents and now the parents receive enough messages, he sends the
message to his parents. But if this guy sends the same message to this node, any more messages to this
node, he is not sending to his parents anymore. He just choose another random node in the next
subtree and sends the message to the next subtree.
Okay. So this is the first step. How to count the messages. Now we can use this step and do an MPC
construction using other construction of the MPC’s. There are a lot of nice works on asynchronous
MPC’s. And assume the circuit has m gates. Most of them have, each party sends O of mn messages
and each party performs O of mn computation, we can use these MPC’s as building blocks and these are
really efficient MPC’s for asynchronous setting.
So we improve the computation and communication costs and in average each party sends soft O of
m/n bits and performs soft O of m/n computation. By this soft O I mean that there is a [indiscernible]
factor in the O that we hided. And we solve the problem with high probability meaning that with some
small probability we may never get the results. If we don’t reveal any information but it’s just there is
no output for the function.
Okay. Now let’s just overview our algorithm views. The quorum construction is an important building
block for us. Each quorum as Matt introduced before has [indiscernible] log n parties which < 1/8
fraction of them are bad. And we use quorum for input counting and instead of every node that you see
in the tree, we put one quorum. So this is the quorum in charge of sending messages up and down to
the parent. And each gate is also computed by a quorum in offsetting.
And we preserve privacy by masking the gate’s inputs and outputs with random values. And the random
values are collective [indiscernible] and collectively known via any verifiable secret sharing. And for the
asynchronous issue we use this t-counter model to count the number of inputs.
Okay. So the tools that we can use is for quorum building we can use BGH13 and for preserving privacy
and computation we can use any asynchronous verifiable secret sharing for support. I choose
[indiscernible] protocol which may be the oldest one. And it actually doesn’t matter. It just changes the
algorithm factor of our protocol. Because everything happen in the quorum. And the quorum is logistic
factor.
So this is the construction. This is the circuit that players want to compute. So each gate is marked to
one quorum. And there is input quorum that not to the input gate and these guys are the guys that
generate that nice data structure to count the inputs. Okay.
So for the input commitment algorithm our quorum for a t-counter, they each party use asynchronous
VSS that’s possible to be a [indiscernible] algorithm or any other algorithm. And it choose a mask and
VSS the mask to the quorum above him. And then it also sent the masked input to the quorum. So this
guy sends his masked input as shares of a random number. And the shares must be secret shares to the
players. So you can say that each [indiscernible] in the quorum has no information about the input. But
[indiscernible] can construct the mass and they can use the inputs whenever they want.
So for the computation phase of the algorithm there are two quorums participate in the algorithm. This
is the quorum associated with the gate and these two quorums are the quorums that have the inputs.
So these quorums, one has the input y1. This quorum two has the input y2 and this quorum generates a
random share. I call it rg. And these quorums together can run any multiparty computation,
asynchronous multiparty computation. And they can generate an output which is the output of the gate
plus some random mask.
So it happens to the circuit and goes off in the circuit until they generate the output of the circuit. Then
they can remask, they can [indiscernible] the mask and so they can find output and send it down in a
tree, in a binary tree.
So in this way any multiparty computation that you want to use, you can use. You can just use this
multiparty computation inside a quorum and the cost for the whole circuit is [indiscernible] instead of
being [indiscernible] and to the tree. For example if you use Aniket’s multiparty computation instead of
getting O of n3, you get O of log n3, which is really, really good. And it’s also really good for in the
manner of designing [indiscernible] and broadcasting. As Juan Garay says, assume that you want to
broadcast, if you want to broadcast between 2 to the 15 number of people or 2 to the 20 number of
people, it’s a huge number of people that you have to broadcast. But instead you can use quorum idea
and only use the broadcast in the 20 people instead of 2 to the 20 number of people.
And it’s really interesting because then you can use Juan Garay’s method or any other verifiable
signature method and you have 2 broadcasts here but 2 broadcasts between 20 people, not 2
broadcasts between 2 to the 20 number of people, which breaks the complexity of the algorithm.
So in conclusion I believe that we have a method that we can use to generate multiparty computation
for huge number of parties. And for open problem I suggest that everybody who has a nice algorithm
for multiparty computation use our quorum to make it more cost effective. Also if you are interested in
designing a scalable interactive computation and a scalable interactive coding for multiparty protocols in
a scalable manner, and using quorums to make them also scalable.
And another interesting open problem is that can we use server based MPC based on quorums? And
the idea is that generating quorums is not easy. And there are algorithms for that but they are not
cheap. And if, you can generate quorums in offline, but it’s still expensive. But if you have a nice server
who can generate quorums for you there is nothing about inputs for generating quorums. There is
nothing about outputs or [indiscernible]. It’s just quorums. So if you have a server you can generate a
quorum. And then you can use your quorums to do the online computation in a resource efficient
manner. And thank you for listening to my presentation. [applause[
>> Seny Kamara: Any questions?
>> Mahnush Movahedi: Yeah?
>>: So the [indiscernible]?
>> Mahnush Movahedi: Yes. Actually our quorum, when we are trying to use this method, we believe
that this method is for a large number of parties. So our quorum size, each quorum must be larger than
20 or 30 number of people. And…
>>: [indiscernible]
>> Mahnush Movahedi: We can tolerate up to an over 8 number of bad parties.
>>: Okay so [indiscernible]
>> Mahnush Movahedi: Yes. Actually, exactly. No. The [indiscernible] protocol you have to run it
multiple times and make it to make sure it’s terminate after some number, some specific number of
times. And I believe you have to run it logistic number of times, which is okay because we are in logistic
setting. So you can afford to run the protocol…
>>: [indiscernible]
>> Mahnush Movahedi: Yes. If you use any less [indiscernible] protocol you have to do that.
>>: [indiscernible]
>> Mahnush Movahedi: Yes. Exactly.
>> Seny Kamara: Any other questions? Okay let’s thank Mahnush again. [applause]