 Hi everyone, so today I will be talking about our work on two-sided motion security for private intersection sum, and this is showing work with my co-authors at Google and with Peihan Nyao, who is studying as a professor at University of Illinois in Chicago. So first I'm going to describe the problem and why we care about it. So our problem is a special case of secure multi-party computation, so as most of you already know, secure multi-party computation is two-party computation. So we have two parties with inputs x and y, and they want to compute functions f and g on their joint input, such that neither party learns anything additional but the other uses input. And so we're focused on this functionality which we call private intersection sum with partinality, where it's basically a special case of secure multi-party computation. Where the output of the parties want to learn is the size of the intersection of their databases, and also the sum of the associated values for values in the intersection. So here the items in the intersection are the intersection between inputs x and y, and one party holds some widths w or values w, w1 to wn, and the party should also learn the sum of the wi for those xi or yi that were in common between two parties. And why do we care about this problem? Well, it turns out to have a great deal of practical applications. So Google recently had a, not that recent, maybe a couple years ago, had a blog post about what they call private joint and compute, which describes exactly this problem. And they talk about many interesting applications to it, including to privately measuring aggregated ad conversions. And Facebook has recently shown also interested in this problem. And they've also had a recent blog post talking about private joint and compute and other answering protocols. And they've also talked about the usefulness of being able to compute sums over intersection in a private way. So this is a problem which we know has a lot of interest in practice. And so just to recap some of the problem, the characteristics of the problem of private joint and compute or private intersection sum of cardality. So in the original work by Google, they discussed mostly honest but curious security, which means participants are assumed to follow the protocol steps honestly, but try to learn as much as they can from the transcript. And the protocol, the applications also assume that both parties receive the output of the protocol. And furthermore, the main measures of efficiency are communication costs and monetary costs of running the protocol. And these those papers claim are more important than internal time. And a special pieces are revealing the size of the intersection is okay or even desirable or useful for some of the applications. This is interesting because in many cases, like where you want to compute over the intersection, like being forced to review the size of the intersection is seen as a undesirable leakage. But in the case of some of the applications, we actually need this intersection side. So in this work, we're going to be focused on keeping all those other constraints that come from the practical applications, like both sides receiving the output, focusing on minimizing communication costs and monetary costs and being okay with doing the intersection says, but trying to beef up the security guarantee that we can provide by providing security against malicious or active adversaries, we can arbitrarily deviate from the protocol in order to try to learn more than they're supposed to. So I'd like to start by first talking about some straightforward approaches that normally you should check when you're trying to go from a semi honest secure portable to security against malicious adversaries. So I'll quickly go through some of these. So the first straightforward approach is to just add zero knowledge proofs to each step of the semi honest portable to make it so that each party has to prove that they did their step correctly. And that's how you normally get the security. But to see why we run into difficulties, let's just quickly recap what happens in the semi honest portable. So you have these parties with their inputs. And what they're going to do is they're going to generate keys for the polling helmet cipher over some group. Let's say it's an elliptic for food for now. And so the first party is going to take each of its inputs and then hash it into the curve for the cipher and then encrypted using its key share K one and send them all to the second party. And then the second party is going to apply a second layer of public helmet encryption and then shuffle these double encrypted values and send them back to the first party. Then the second party is going to single encrypt its values y1 to yn and then also send along its associated values w1 to wn encrypted using an additive homomorphic encryption scheme. And the first party is going to add it the encryption layer of K one to the second party's inputs. And then now both parties parties is inputs are in this double encrypted space encrypted K one and K two. And so the first party can just determine which of the items are in the intersection and thereby learn the intersection side. And then also add together the corresponding homomorphic encryption to get an encryption of the intersection sum. And then send this back to the first part of the second party to get decrypted and send it back. Let's help with parties to the cardinality and the sum. So now the first problem we get when trying to add proofs everywhere here is it's easy to prove that everything is exponential to the same exponent. But actually we also have to prove that the thing that's being exponentiated is a hash or something to the curve. And then proving this hash actually turns out to be very annoying and expensive. So that's one problem with following this first recipe. And the second thing is the first party, you know, does this thing of figuring out what things are in the intersection and sum the corresponding values together. But how is the first party supposed to prove to the second party that it's summed the right things and not just whatever it sounds like? Like this also turns out to be quite an annoying thing to prove to create a proof for. And so this is the second difficulty that we get when trying to follow this strategy. So the strategy is, and we'll tease you. So the second strategy is to take an existing protocol that gives malicious security for private side intersection. And but that only has one sided output and then transform it into a protocol that has two sided output. And there's actually several excellent works that get very efficient protocols for private side intersection with one sided output of a security against malicious adversaries. And the standard way for turning a one sided output protocol into two sided output protocol is to have both parties commit to their inputs, and then run the protocol first in one direction and then in the other direction. So one party being the output receiver and the other party being the output receiver. And then in each of these executions proving that the inputs used by the parties are the committed inputs. And this is a straightforward recipe and it works. But the problem is proving using any of those existing protocols with proofs that you use the inputs that were committed to actually turns out to be not straightforward and has a bunch of expense. So basically this also runs into this problem that is not easy to compose these protocols with the inputs. And the third option is to use generic secure computation techniques. And there are actually great works that do this as well. So one promise one is one that uses garbled circuits in order to do private side intersection using the so called sort comparison for technique. And this is great because this actually extends straightforwardly to malicious security. It also enables two sided output for the protocol and it also enables computing functions of those will see the data for things in the intersection. But the problem is that these generic techniques usually incur very high communication costs and because of that very high monetary costs. And this is usually because in order to do these techniques you have to bitwise encrypt each of your inputs and that causes a large communication rule. So our approach or our contribution is going to be to give a new protocol that gives private side intersection with cardinality. Security guys malicious adversaries supports two sided output and has communication costs that's only modestly larger than the semi honest protocol based on decision to fee helmet. It's a private journey compute protocol and monetary costs that's somewhat larger than the semi honest protocol based on dvh and here monetary costs are going to measure using resources for cloud machines from a public cloud provider. Okay, so now let's start getting into what our exact construction is. So our idea is going to be kind of to follow the recipe for the private journey compute protocol. And inside that our first step is going to be to build a distributed opiata. The delivery opiata is where two parties have shares of keys k1 and k2. And one party has a bunch of inputs. And at the end of the distributor opiata protocol, both parties are going to learn the evaluation of a pseudo random function f, which has, you know, both case k1 and k2 as is key and evaluator on each of the inputs. And the reason that both parties can learn the output is that like as long as not both the part like neither party has both the key shares that the output is going to look super random to each of the parties. So our first idea is to build a distributed opiata protocol. And of course, secure against malicious adversaries. And then we're going to extend this so that the party who provided the inputs is not going to learn the outputs in the same order, but it's going to learn them in shuffled order with the order of shuffle and chosen by the other party. And the point of the shuffling is so that the party is not going to be able to figure out except later on the party is not going to be able to figure out exactly which items are in the intersection, but rather it's only going to see how many items are in the intersection. This is similar to the strategy taken in the semi honest protocol. And in order to achieve the shuffling with malicious security, we're going to use a shuffle proof. And there's many of these in the literature, we're going to use a specific one, which we'll talk about later. And so once we have the shuffle of distributed opiata, we're actually all set to get a protocol for just the PSI cardinality part of the problem, which is to find the intersection phase. And the way we're going to do this is we're just going to have the SDO PRF evaluated first on parties inputs, and then evaluated on the second party's inputs, and then we have to do it with the key the same keys. And since the SDO PRF has the property that both parties receive the OPRF evaluation. Now both parties can just look at the transcripts from each of these two different protocol executions, and see how many of the opiata outputs were the same between the two, and that's how they can figure out what the intersection size is. And so this gives us cardinality and then now if you want to extend to some, so now one party has these associated values, what we're going to do is use a homomorphic encryption of the associated values, and these are going to get sent along in the shuffle of the opiata evaluation in the second part. And this homomorphic encryption is going to be a split key encryption so that the key is shared between the two different parties, the decryption key. And we're going to kind of provably shuffle and re randomize the encryptions of these associated values with the same permutation that's used to shuffle the opiata valuations of the y values. And then in the output of this, so the output of this protocol will be the opiata values and also the associated encryptions of the w values, but shuffle and re randomize for the same shuffle. And then once you have this, both parties can again look at the transcript and see which of the opiata values are in common across the two, and then add together the associated homomorphic encryption values to get an encryption of the intersection sum. And then once you have this encryption of the intersection sum, the parties can interactively and provably decrypt this value to get the actual intersection sum. And we note that this fact that both parties can look at the transcripts and see exactly which opiata values are in common, and then deterministically add together the homomorphic associated homomorphic encryption. This avoids that major headache we talked about, which is how is one party supposed to prove to the other party that this homomorphic encryption of the sum was created correctly. Like here, the point is that both parties can do this independently and deterministically create the ciphertext that has the homomorphic encryption of the intersection sum, so no additional proof is needed, like both parties know what the ciphertext is supposed to be. Okay. So this is our recipe. And then now we can talk about what exactly is the opiata value we're going to use, and then we'll talk about exactly how we implement to each of the steps of the protocol. So the opiata value we're going to use is a variant of the so-called Dodis Jampalski PR, which is also sometimes called Bonaparte PR. And the variant we're going to use is one that allows split keys. So the normal PR just says one key K, and the evaluation is G to the one over K plus X. But for us, we're going to have additive shares in the key Q1 and K2. And the security of this PR can be based on the Q inverse EDH assumption in the group generated by G. And it also turns out there's interactive protocols to compute this PRF, not in the split key setting, but in the single key setting, but we're going to do a variant of those. And those protocols leverage the command-and-shoot cryptosystem. So this command-and-shoot cryptosystem is an additively homomorphic encryption scheme, and it supports proofs that you encrypted a value and proofs that you decrypt a value. And so now we can get into exactly how we're going to implement our distributor OPR. So let's just assume the first party has the inputs right now. And now both parties are going to generate key shares for this distributed OPR. And they're going to agree on a generator G for a group capital G and that the order of that G be Q. This Q is different from the Q and the Q inverse EDH assumption. But here let's just think about Q as being the order of this group. And so the part, the second party, the non-input-providing party is going to send a different encryption of its key share K2. And the first party is going to use the homomorphism of the command-and-shoot encryption to send an encryption of K1 plus K2 plus XI for each of its inputs XI. But actually this on its own is not secure. So actually the first party is going to mask it using random masks AI and BIQ. So AI is going to mask the key of K2 plus X and BIQ, this thing is there because basically the message space of the command-and-shoot encryption scheme is different from the X1 space of G. And so this BIQ is kind of simulating a mod Q operation within the pain type space of the command-and-shoot encryption. That's why I started. And so the party who receives the command-and-shoot encryption is now going to decrypt it and then inverted and exponentiate G to the 1 over AI, all this stuff, whatever decrypted. And because the order of G is Q, the BIQ part disappears, you get 1 over AI K1 plus K2 XI. And then the receiving party can just remove the power AI by exponentiating it to AI. But actually we do a small optimization to make this a little bit more efficient, which is that the first party is actually going to send along G to the AI along with this command-and-shoot encryption. And the second party is going to use this G to the AI to exponentiate with the inverse. So instead of using G, it uses G to the AI. And then the AI is automatically going to cancel out. And so the result is actually going to be already F evaluated, the distributed will be evaluated on XI. And so this is exactly our distributed opiera protocol and both parties get the output. And in addition, we have to have a ZK proofs for each thing. And it turns out that a command-and-shoot encryption and all these other things, all these other operations are a manifold to different kinds of ZK proofs based on Sigma's protocol style proof. The special piece that we need to note here is actually we need to do, all our proofs need to have a range proof component to it because the orders of the groups that we care about are different sizes. So in order to prove that if we wrapped around in both the groups, then we could have a problem. So you need to do a range proof to show that you didn't wrap around in at least one of the groups. Okay. And so this is our thing for the opiera. But now what if you want to shuffle the opiera? But what we're going to do is instead of sending, instead of the second party sending back just the, you know, the opiera of evaluations, it's instead going to send back LKMOL encryptions of the opiera of evaluations. And then it's going to send a shuffle and decryption of those LKMOL encryptions. And this is how we're going to implement our shuffle. So if the changes are, it's sort of sending the opiera values to send LKMOL encryptions. And now if the change are approved so that we have to prove a set of saying that we decrypted this second party, decrypted the value and exponentiated the inverse. It's going to be decrypt, invert, exponentiate, and re-encrypted LKMOL. So it's a slightly more complicated proof but also very doable. And then also we add a second proof which is going to be a shuffle and decrypt of these LKMOL values. And for this we're going to use a proof from Bayer and growth from Europe of 2012. There's many different ones, but you just use this one because it seemed the most straightforward template. And now we have a protocol with those components. We have a protocol for malicious PSI cardinality. And now if you want to extend to PSI sum, we're going to do what we talked about before, which is that we're going to get this split key homomorphic encryption scheme. And specifically we're going to use split key exponential LKMOL for our additive homomorphic encryption scheme. And it turns out if we use exponential LKMOL as our homomorphic encryption scheme, there's a problem that the values need to be bounded into something that can be decrypted by a discrete log. But that turns out to be okay for most of the applications that we care about. But if we use this exponential LKMOL, it turns out that this is very compatible with the shuffle proof that we use for the DOPRF section. And the shuffle and re-randomization can be added on to the shuffle and decrypt from that we already had with the small additional cost. And so that's exactly what we do. And as you mentioned before, both parties can now figure out what's the encryption of the intersection sum and then we do an interactive decryption proof. This is also straightforward for exponential LKMOL. And so this is essentially a protocol and there's a few additional tricky parts here. So one first tricky part is that unlike some of the previous works, we don't assume a trusted modulus for commitments and commensure encryption that was assumed by some of the previous works. And so each party is going to independently generate its moduli for commensure encryption and then they're going to have to prove to each other that these moduli are okay. And then a second big issue is that many of these proofs are crossing different groups and so a lot of care needs to be taken like this is a massive place for fit balls and soundness errors with with different CK proofs and we have to really carefully use the strong RCA assumption and QC's bridge commitments in order to make sure that everything works okay. And then in other important pieces that we had to design a custom decrypt invert and exponential proofs, a decrypt can manage to invert and exponential and encrypt with LGMOL and a standard sigma protocol doesn't work in this case. And finally it turns out the Q inverse DDH assumption which gives the security of the OPRF assumes a polynomial domain so that would restrict the X and Y values to be from a polynomial size domain. But it turns out we can get around this by if we commit the inputs beforehand. If each party commits X and commits to Y beforehand before choosing the keys for the OPRF then it turns out that it can be an exponential domain as long as the number of as long as the input sizes are a polynomial, like the number of inputs is polynomial. Okay and then furthermore we have a whole bunch of batching techniques that you described in the paper and these batching techniques are crucial to getting the communication cost to be very low for the CK proofs and also for the other component. So one is that we use a heavily batched version of Kermana-Schrupp encryption. So Kermana-Schrupp encryption is a big chunk of the communication cost of the protocol and it actually has a forex communication overhead between the plain text and the ciphertext. And so the batching that we do here is a combination of the batching techniques from Elkamal encryption and Paellae encryption. So Kermana-Schrupp can kind of be thought of as a hybrid between Elkamal and Paellae. And so one of the optimizations is to reuse the first component across multiple ciphertexts like a common optimization for Elkamal encryption. A second one is to use Damgar-Zurex style optimization as it's available in Paellae encryption which is to do everything mod n to s plus 1 instead of just n square. And the tricky part here is that we have to this ends up blowing up the plain text space and so we have to modify the protocol to batch multiple OPR evaluations into a single membership ciphertext and show how it does. And this has a big impact on the communication overhead factor for Elkamal-Schrupp. And the second big kind of batching that we do is batching the Sigma protocol. So there's two points to note here. So one is that since we have to all our proofs need a range component we actually modified the standard way of batching Sigma protocols so that we more carefully control the slack induced by the batching. The slack in the range proves induced by the batching and this has a big impact on our communication overheads. And the second is we give a new batch proof for Komen-Schrupp decryption and technically for the decrypt invert exponentiate proof. And overall this makes it so that our proofs are asymptotically sublinear in the input sizes and the proofs actually become a very small part of the overall communication cost in our concrete measurements. And so then finally I'd like to talk about some of our measurements for our protocols and comparisons with other works. Our first comparison is going to be against a semi-honest EDH protocol when we try to aggressively minimize the communication costs. And it turns out if we use very aggressive choice of batching parameters and we can greatly reduce the communication costs to something very competitive which between four and five X expansion over the semi-honest EDH base protocol. But it turns out that this has a large impact on the computation costs so if we try to instead minimize monetary costs we end up with parameters that give like less of a communication give more communication costs but much lower computation. And so here we have like a seven X increase in communication and overall we have like a 24 to 25 increase in monitoring costs of executing the protocol. And this monetary cost uses these costs for resources from Google Cloud Platform but for AWS and Azure it's pretty similar. And in terms of comparing to other protocols that try to do malicious PSI we note that the sort compare shuffle is the most prominent one that gives to set it up with competing over the intersection and in this case we have monetary cost which is like 10 to 50 times better and communication costs us a lot lot better than this work and actually you can see that even relative to the very efficient one-sided PSI protocols the malicious secure PSI protocols we only have a moderate monetary cost increase even though we give two-sided output and compete over the intersection. We note that this comparison doesn't include a very recent work from EuroCorp 2020 which actually has a much better monetary cost than the previous works but we note that this new work also only has one-sided PSI so some significant extra cost is needed in order to make it two-sided PSI and to support computing over the intersection. Okay then with that I'd like to thank you and thank you for your time.