 שוב, אני אורי וזה בע Kenneth ואיפטח היטנר וכוביני סין על הרי מקורדת ובשפל מודל ובסלב, אנחנו נשאר על השפל מודל בקלטים של פריוון. אז first let me start with the definition of differential privacy. So it's a mathematical definition for privacy saying the following. Let's think about a database that contains the information of individuals. So every row in this database contains the information of one individual and we have an algorithm A that we want to apply to this database. So now let's think about the following mental experiment where we modify our database to what we call a neighboring database. And what it means is that all of the rows remain exactly the same, except that one of the rows in the database, let's say my row, we replace it with something completely different. So we have these two neighboring databases. Now we run the algorithm and what we require is that the outcome distribution of the algorithm remains roughly the same between whether we run it on the first or on the second database. Formally, an algorithm is differentially private if for every two neighboring databases S1 and S2 and for any possible event H, this event occurs with roughly the same probability between whether you run your algorithm on the first or on the second database and this similarity between the probabilities is quantified using these parameters epsilon and delta. So that's the definition of differential privacy. So we like it. So the reason is that it has a like a very intuitive interpretation for privacy specifically, let's consider an adversary that knows all of the rows in the database, except for my role. And now we take this database and we run our algorithm on it, we get an outcome, and we give this outcome to the adversary. Now this adversary from his point of view, he cannot learn basically anything about my role in the database because from his point of view, no matter what was my role in the database, he would have seen a sample from roughly the same distribution. So that's the intuitive explanation of differential privacy and also this definition satisfies several useful properties which I'm not going to get into now. Okay, so that's the definition. And what I'll show you in this slide is kind of different models using which we can apply differential privacy in different settings. So the first model is called the centralized model for differential privacy. This is like the standard model. It kind of fits the picture that I showed you in the previous slide. So we have a collection of any individuals, users, where each user has his own private data or input. Now, each of these users just gives their data, as is, to a data curator. So the data curator now has a database containing information from these individuals, and now the data curator aggregates this database using differential privacy. So it runs a differentially private algorithm onto this database obtains an outcome and publicly releases this obtained outcome. So by the definition we mentioned in the previous slide, we know that this outcome that the curator obtained here is really safe for publication in the sense that every attacker who would see, who would get to see this obtained outcome, would learn basically nothing about the data of every single individual from here. So that's great. But the downside is that, as you see, the data curator, he learns everything. All of the users give their data, as is, to the data curator. What happens in cases where we don't want the curator to learn all of our data? So the first model that was considered in this setting is called the local model of differential privacy. And in the local model of differential privacy, every user randomizes his data locally on his device using a differentially private algorithm, and only sends the data curator the outcome of this differentially private outcome, which is already safe for publication. So in this model, even the data curator basically learns nothing about the data of every single individual, because every single individual only sends the outcome of the differential privacy algorithm on his data. And then the data curator aggregates this noisy message as it gets from the users and computes whatever it wants to compute. So again, the data curator basically learns nothing about every single individual, which is great, but the downside is that because every user adds lots of noise to its input, then accuracy is generally significantly reduced compared to what we can achieve in the centralized model of differential privacy. So this motivated the shuffle model of differential privacy, in which we augment the local model of differential privacy with a special communication channel, we call it a shuffle channel, such that the following happens. In the shuffle model of differential privacy, like before, every user randomizes his input locally on his device and obtains a noisy message, and then all of the users submit their noisy messages to the shuffle channel. This channel randomly permutes all of the messages it gets from the users, and then gives the data curator these messages after the random permutation. So the hope is that this random permutation kinda disassociates the messages from the users who sent them. And then the hope is that, because we have that, every user can add less noise to his input before submitting it to the shuffle, and therefore, hopefully the database that the curator would get here at the end, we could get a lot more utility out of it than what we can do in the local model of differential privacy. Okay, so that's informally the shuffle model for differential privacy and the motivation for it, and here is the formal definition. So we consider protocols that proceeded in rounds, let's say other rounds, where in every round, every user submits L messages to the shuffle. So here in the picture every user submits only one message, but let's, but in general we allow users to submit more than one message. So we have N users, each of them submitting L messages in every round, so in every round we have overall N L messages, the shuffle randomly permutes all of these N L messages, and then everybody gets to see the outcome of the shuffle. And what we require is that, the view of every coalition of up to T parties is differentially private, in the sense that, even after it gets to see the outcome of the shuffle, it learns basically nothing about the input of every user outside of this coalition. Okay, that's the definition of the shuffle model. And recently there has been lots of works on the shuffle model in the context of differential privacy. First it was defined by these guys in 2019. And then for our papers show that in many cases we do really get significant utility improvements over what we can obtain in the shuffle model of differential privacy. Sometimes we can even match what we can get in the centralized model of differential privacy. For example, people considered problems like addition histograms and more, and also several papers showed impossibility results for one round shuffle model protocols. Actually, this model was already defined outside of the context of differential privacy in 2006 by Ishae et al. So they presented and they defined and consider the similar model and in particular they showed that every finite functionality can be securely computed in this model. So assuming an honest majority using a constant number of rounds. Okay. What we show in this work. So we studied the round complexity of protocols in the shuffle model of differential privacy, we are the first to formally or explicitly studied around complexity in the shuffle model. And specifically what we show is first we present a generic result showing that any functionality can be computed in two rounds, if you have an honest majority. And also we present separations between what can be done using one and two rounds in the shuffle model. In more details. We show both positive and negative results. First, we show a protocol for secure message transmission in one round in the shuffle model and I'll tell you more about this result in the next slides. And we use this result in order to show a generic construction. And that any finite functionality can be computed. If you have an honest majority using two rounds previously what was known using the results of Ishae et al was three rounds. And as a corollary. This means that we can implement using two rounds in the shuffle model, every centralized model DP functionality. So that's our generic construction and we also show separations between what can be done in one and two rounds and specifically to obtain our separate separations we consider these two problems. The first we call it the common element problem and the second we call it the nested common element problem. So for the common element problem, we show a lower bound on the message complexity of any one round protocol. Informally, it says that if you want to solve this problem, the common element problem using one round, using a one round protocol in the shuffle model, then basically your message complexity cannot be constant. In contrast, we show that there is a two round protocol for this problem in the shuffle model in which the message complexity is one. Okay. Our second result, our second lower bound is for the nested common element problem. And for that problem, we show that there is no one round protocol that solves this problem. Even if you assume that you have three quarters fraction of honest users. So this immediately implies a strong separation between one and two round protocols, because by our generic construction, every functionality and in particular the nested common element problem can be solved in two rounds, if you have an honest majority. Even for that specific problem, we design a specific protocol that obtains better guarantees than our generic construction, but even the generic construction immediately gives you a strong separation between one and two rounds. Okay, so that's our results. What I'll show you now is how do we construct a secure message transmission in one round. So, before I'll show you how do we construct it, let's do a quick recap and recall the definitions of key exchange and secure message transmission. Let's start with key exchange. Let's think about two users, user i and j, that first submit messages to the shuffle, and then everybody gets to see the shuffled messages. Then user i and user j agree on a key, but all other users, together even, they get no information on the key. So that's the definition of what we want from a key exchange protocol. The definition of secure message transmission is similar, but now user i, before we start, it has an input message m, then users i and j, each of them submit messages to the shuffle, then everybody gets to see the outcome of the shuffle. Then the requirement is that user j learns the message m, but all of the other users together, they get no information on the message m. Okay, so that's the definition of what we want from a secure message transmission protocol. And I'll just mention that Isha' et al, in their paper from 2006, they presented a key exchange protocol in the shuffle model that uses one round. And obviously if you have a protocol for key exchange in one round, then you can use it in order to construct a secure message transmission protocol in two rounds. Where in the first round, users i and j exchange a key, and then in the second round, user i sends the message to user j privately after encrypting it using the key. What we show is a protocol for secure message transmission in one round. So let's see the details. But before I'll show you the protocol for secure message transmission, let's first see an easy protocol for key exchange. So it's a variant of the protocol of Isha' et al. And here is the protocol. So users i and j, each of them chooses a random bit, user i chooses a random bit A, user j chooses a random bit B, and they both send it to the shuffle. Now, if A is different than B, then the common key is A. Otherwise, the protocol fails. So why should that work? So first, both users i and j, they know the key. Why is that? User i knows A, he chose it, and user j knows B, so once she sees the outcome of the shuffle, she learns A. All of the other users that see the outcome of the shuffle, with probability half, they see A, B, and with probability half, they see B, A, so they get no information on A, assuming that A and B are different. And so this means that users i and j, they agree on a key with probability half that nobody else knows. Great. So what do we do if we want to agree on a key of k bits? So we do something similar. But now, each of the two users, instead of choosing just one bit, they choose a random 3k random bits. So user i chooses random bits A1, A2, till A3k. So user j chooses random bits B1, B2, and so on. And they submit to the shuffle 1, A1, 2, A2, and so on. And user j submits to the shuffle 1, B1, 2, B2, and so on. So we expect that on half of the coordinates, we will get that ai is different than bi, and with high probability, we will have at least k such indices. So after seeing the outcome of the shuffle, we denote by i the first k indices such that ai is different than bi, and the common key is the ai's from this set of indices. Okay. So this is a simple protocol that allows these two users to agree on a secret key with high probability, and the key is of length k. Great. So once we have a protocol for key exchange, then Yishai et al observed that we can use it in order to implement secure computation in the shuffle model. So how we use, we use one extra round in order to use the key exchange protocol in order to exchange keys and therefore create private channels, and then we apply an existing MPC protocol after we have private channels. So a corollary of that, if you combine this idea with the secure two round protocol of apple bar metal, then what you get is a generic secure computation in the shuffle model that uses three rounds. Okay, so what I'll show you now is a different key exchange protocol in which one of the two parties knows the key in advance. So here's the protocol. Now, each of the two users chooses a collection of seven k random beats, so user i chooses a one a two and so on user j chooses b one b two and so on. And like before they submit to the shuffle one comma a one two comma a two and so on and likewise here. Now, for a hash function h that maps seven k beats to k beats, the common key is h applied to the collection of the random beats ai. So observe that user i knows the key in advance. So why should that work. So first user i knows the key and also user j after seeing the outcome of the shuffle. It learns the ai's and therefore learns the key, but all of the other users in places where ai is different than bi do not learn the ice bit of the key. So we expect them to learn half of the beats, so 3.5 k beats we expect them to learn and with high probability, all of the other users know less than 4k of the beats from the ai's. So by the leftover hash lemma, this means that h applied to the ai's remains close to uniform even when the other users know 4k of these beats ai. So this means that users i and j agree on a key, user i knew the key in advance, and all of the other users basically learn nothing about the key. So this means that we can implement general NPC in the shuffle model without increasing the round complexity. Specifically, using the upper bottom at all protocol, we can implement it in two rounds, because during the first round we both exchange keys and send the messages required, that we're required to send by the ABT protocol in the first round, and then for the second round, we have secure channels. So, to conclude, what we present is a generic NPC result showing that any finite functionality can be computed using two rounds, assuming an honest majority in the semi honest setting. In particular, this means that any centralized model. Dp functionality can be computed in the shuffle model using two rounds. And we present impossibility results for one round protocols that gives the operations between what can you do in one and in two rounds. And that's it.