zkSummit6: Privacy-preserving Insight Generation Across Siloed Databases – Daniel Benarroch – Qedit

Transcript

[Music] and we're back for the first talk of day two of the zk summit we're here with daniel benarash from kedit he's going to be talking about privacy preserving insight generation across siloed databases so take it away daniel and if anyone has any questions please remember to put them in the stage chat and we're going to do a q a after the talk cool thank you so much anna and thanks everyone for for being here um i'm very happy to be talking today at the ck summit uh it's actually the first time i'm talking here which is really

exciting for me i'm the director of research at cadet a company building enterprise products for privacy data collaboration private data collaboration some of you may know me from zika proof i'm a co-organizer there so happy also to uh to answer questions about that if you have but anyway this this talk is not about zk proof i'm uh going to so uh just throughout the conversa throughout the presentation please feel free to ask questions on the chat uh feel free to to sort of um you know i i won't be looking at the chat but you know if there is anything important then i'm sure we can talk about it either at the end or during but anyway i

would like to um to talk today about um sort of how to generate insights across um from from private data that are that is distributed or that is coming from different sources right um so the goal is is exactly that like you have sort of different parties say alice and bob and charlie that have their own databases uh and of course this is databases that must be kept private um but we want to essentially be able to compute on the sort of uh having these databases as inputs right of course we know that there is a primitive called multiparty computation that does this

and there is today a lot of interesting products and work being done um the only sort of challenge here requirement is that when you do mpc in a cryptographic way you know that you need to have uh the actual sort of server that will you know enable the computation on your end and and many times these generic npcs are very interactive so you need to be online right we know this we know this from from several settings whereas what we need you know when we're selling uh products in to enterprise is something more that is something closer to like software as a service right where you're just sort of logging into your account on the browser and you have all the data and all the uh

product available you know just for a a click away kind of thing so we don't want the the clients the customers to to have to sort of install servers uh that they need to maintain we don't want them to have sort of interaction between the servers which is you know one of the biggest requirements that we have here and uh that kind of says that the reason for that is that we don't want to force them to stay online right because it's definitely a sort of um against the business or usability proposition and if possible we would like them not to have to maintain private keys right permanent private key so aside from from this um yeah so no private keys

um and in terms of sort of the product itself like what what does it mean to generate insights well there are sort of two different ways of generating insights across databases right you have uh one where where you could for example say okay i'm going to to sort of compute an insight or aggregate data uh from two different sources about the same entity right it could be a company it can be an individual etc or you could essentially say okay i'm going to collect data uh uh from from say like an industry specific uh use case or something and you know i'm gonna give back some i don't know industry statistics or benchmarks to give like a high level picture of the of the industry right and uh these these are just

sort of two of these but these are the ones we kind of focus our product on and here really the challenge is that um we want to actually compute cryptography in a secure way right we don't want to give in sort of use uh you know have the data and then just give insight like there's plenty of companies for that this is not uh the premise and we do privacy by design right and so the key challenge is how do we do cryptography securely on a decentralized sort of server on a centralized server sorry right not decentralized as as we are used to thinking in cryptography of course you can think of several uh things uh uh um you know cryptographic uh primitives like homomorphic encryption

which is already practical a lot of people are using it but it's not really usable right the difference there between practical and usable is that you know it will take you you know a few hours maybe a couple of days to to compute on really large data uh some some uh you know maybe some large circuits and so on but it's not usable in the sense that if i'm you know a user uh logging in and going online and you know uploading some data to get some some you know insights from my data i don't want to have to wait a day right i want to upload it get some data maybe maximum i don't know an hour maybe a couple of hours did i go get a coffee go get lunch something like this but i'm working right it's my day they work so i need to do this

and of course you know we could we could use other like more specific purpose ones but we need to think that the functionality there is really limited by the cryptographic scenes for example like functional encryption attribute based encryption order preserving encryption all of these things are are well known and used in some settings and so what are some of the the insights that we could generate you know while uh data ownership is key really the the collaboration part is where the value generation is going to be for companies right so we have something like uh you know sharing insights in general where for example the goal is that alice will share with bob some insights from her database and here maybe the the key is sort of saying okay how does bob trust the insights right and this is also some

some somewhere where uh zero knowledge comes in right we all we're all aware around this issue of integrity of data and computation um there is the um sort of a different use case which is more around aggregating data right if you have alice bob and charlie who wants to sort of compute the average of some values either you know their own values or say you know uh about some specific individuals uh you know for for say fraud prevention right uh in in financial settings um and the challenge here is that you must keep all of those values private uh and actually receive the correct average right and the last sort of uh use case that that you know example that we have is um matching

identities right so again alice and bob want to uh you know they have companies and they want to know what are the clients that they have in common you know maybe they're going to have some kind of joint marketing campaign their partners and they want to generate uh you know more assurance for example for kyc purposes um and here the challenge is again that you know alice cannot learn the clients that are not common the bob's clients that are not in common and vice versa right um and for these we this last one we also use sort of this idea of psi right psi is a private set intersection and what we do at credit we call our protocol the delegated psi protocol where we're going to actually do the the

sort of two steps right we're going to first match some specific entries between data sets that are distributed across parties and then we're going to use other tools to aggregate those those data or values that that come associated with with that data in order to generate insights um so just a quick sort of overview i'm going to talk about sort of the different primitives that that we're going to use uh i'll i'll present and introduce them as we go first let's talk about what is private cell intersection right so as i said it's a very powerful technique for detecting matches and duplicates across databases so if you have alice uh for example i see alice's customers

on the left and bob customers on the right you really want to get to know all these sort of red triangles in the middle right but the key point is as i said that alice should not learn the white triangles and bob shouldn't learn uh the blue triangles right and how do we do this well one you know going back to sort of reminding uh uh the the requirements the desired require the design requirements is that um we have sort of these usability models right where we want the participants essentially uh to have offline communication where we want the the participants to just send one single message to kind of upload the data and one message to receive

the results right of the matches and insights um we call that the offline offline method offline model we also want in terms of states that the only state that they will maintain that the participants will maintain is their actual database right we don't want them to have like permanent keys and if there are any keys maybe we can get them to be like per session for example per upload right uh just temporary and local um and uh in terms of server as we said we don't want them to have any server right so at a high level what we do essentially is that we're actually delegating sort of if you think about uh the generic psi uh protocols that exist out there we're delegating you know the interaction between the the participants in the mpc to some servers that are kind of

sitting in a secondary line okay and we call these the delegates so the clients are the participants and then we have another set of servers that we call the delegates and this is how it really looks like you have the participants um that are sort of connected to a single entity which acts as a proxy which is which we call the matcher as well and also you have the delegates connected to that so there is uh you know the participants interact only with the proxy as well as the delegates and there are secure communication channels between the delegates and the participants right so that the matcher is not sort of an eavesdropper and this this allows us to essentially uh remove all interaction and all servers and things like this from the

participants now there are a lot of existing works in psi but we actually deviate from those um a little bit right we do use reuse some of the components because actually most of them require this interaction that i'm talking about that we don't want uh in our product uh there are some works that are like surveyed server aided psi like like google and facebook have have done some work in that uh area um but there is still like the component of of having to to interact several times from the um side of the participant and for our delegated psi what we use is sort of a combination of you know secret sharing scheme and and oblivious prfs uh and you know some some other nice tricks

um around this interesting architecture right um so let's start by talking about secret sharing right the specifically the secret sharing that we use is very convenient and it's sort of this multiplicative secret sharing where essentially you have here sort of these delegates d1 d2d3 and each delegate is going to generate their own key right key one key two and key three and then what's going to happen is that for example the first delegate is going to take some some group element g that is public or known to everyone and he's going to compute uh g to the one right and then he's going to send g1 to to the delegate two and delegate two is going to add right on the exponent uh his secret or her secret

uh and similar for uh the third delegate and at the end of the day the third dialogue is going to output the aggregate the aggregated key right um uh g to the k um so yeah so that's a that's a typo it shouldn't be it shouldn't be uh g here it should be g to the k where k is essentially the product of the three values right of course there is also like additive secret sharing and things like this but we're interested in this specific um secret sharing scheme because it doesn't have actual interaction and things like this it's easy to generate and it's also secure by by the discrete logarithm um then we're going to use the prf right prs stands for pseudorandom functions and the specific prf we're going to use is sort of a hash

to group function where we take a hash function like sha 256 which we call here h and we're going to map it into a group okay so this is going to actually be a hashtag group if this is reminiscent like uh in the sapling protocol that was introduced also uh there is actual you know standards around this uh for specifically the restretto uh group um and uh then this uh hash to group now being inside of a group we can actually exponentiate by some integer value right or fill element and this is we know we call this f of kx because it's a keyed uh hash and then it becomes a prf and there are like two main properties that

we're interested uh first first one is really sort of randomness where as long as k is uniformly random then you know f of kx is actually uh super random and and hides x and you you uh disable sort of brute forcing and then you have this property of linearity right which is sort of key homomorphic in some sense and then what what happens is that if you do uh f f k one of x two to the k two uh you actually get f k one k two of x right similar uh to how you would do uh the secret sharing operation right um and so what we use is actually not not sort of a pure prf per se

we use something that that is called more like an oblivious peer we actually use a different version of an oblique sprf but let me build that let me build that concept so in an oblivious prf what happens is that there is a participant and a delegate or a server in this case i'll call it the delegate and the participant is going to compute this this prf uh by using sort of a random element right a blinding factor let's call it r and so it's going to output c which is uh this f r of x and it's going to send c to the delegate and then the delegate is going to add the k to the to c right so it's going to send back c to the k which is really

f of r k to the x right of x sorry and um here what we see is that basically the participant inputs a value x the delegate inputs a value k and what happens at the end is that the participant is going to remove the blinding factor that it added in the first place in order to hide x right it's really there to for doing that but now the output is really f k of x and now we can see that sort of f k of x is the output of the of the uh protocol for computing the the prf where the participant doesn't know k and the delegate doesn't know x okay and this is very important um specifically i can give you sort of a a

glimpse into the into the next slides where if you think about doing uh you know this this oblivious prf for x and y at the end of the process fkx and fky you can check whether fkx and fky are equal because if they are equal then the hash being deterministic is the prf being deterministic is going to give you the same value while being secure right and not being able to learn the actual values um but in our psi because we said that we actually delegate sort of the mpc and the matching uh we actually need the delegates to see the output of this oblivious prf and in the process why don't we try to take a to remove one round of interaction right so

here we have sort of three rounds right or sorry two messages but if we wanted the delegate to see the prf we would need sort of a third round where the participant sends the the um the output right well actually we want to remove sort of two messages uh completely so there's it's gonna be a purely based on one message and how do we do that where now the participant instead of sending only c uh and this is by the way is a straw man you'll see why it's a stroman example but uh we'll see the real thing in a second uh instead of only sending c he's going to send c and r r being the blinding factor and of course now you know that's why it's not secure the delegate can already like brute force and get x but just bear

with me for a second because it's there is some insight to be shared here and um the delegate is going to again add the the key so it's going to compute fr k of x and at the same time it's going to remove the r right and at the end he's going to see fk of x but again of course this is not secure so what is going to be our solution is going to be to distribute r and k using a secret sharing scheme right because again if you had the delegate even even without seeing r if the delegate could compute fk of x and it knows k it can again get x right so we need to distribute both r and k using secure secret chain and that really just brings us to the

actual protocol flow where um i hope i hope you can see this uh sort of big enough but essentially here we have again like the participant data being x and what happens is that the participant is going to blind uh sorry samples some some random values some random shares r1 to rn because now we have m delegates and that you know the multiplication of these the the product of these is going to be called r which is our blinding factor and then the participant is going to do two things it's going to compute the prf right h of x to the power of one over r right so just for convenience of of later removing

the r so it's going to to exponentiate by the inverse of r in the field uh and we're going to call this d0 right um and at the same time it's going to send each of the shares of r right the blinding factor to each of the delegates and now um let's start for example by by the first delegate in series you know as as we saw in the secret sharing scheme by by making the shares multiplicative the way which works is that d0 is now going to be sent to the delegate to delegate one and each delegate is is sort of going to remove a little bit of of the blinding factor right the corresponding share of that blinding factor that they own and they're going to add their share of

the key right so k1 as you can see here d1 is just d0 to the power of k1 r1 and this is going to be sent to the delegate 2 who's going to do the same with their own key and and stick and blinding factor share until we get to the last one who is going to do exactly that uh d sorry m minus one this should is again a typo so i'm just so sorry about that to the power of km rm and that's going to remove the last part of of r and is going to add uh the last share of k right where k again is k1 to km and now this is going to be sent to sort of this proxy or matcher like we we sort of overload that proxy um

sort of party in the in the middle of the network and i'll explain why and i can answer some questions uh around that as well um but uh this is essentially the the delegated psi protocol well the point is that now the matcher who is going to receive you know several of these elements from different x's for a given participant but also from different participants can actually compute some matches over encrypted data right and here the important part to keep in mind is that as long as one delegate is honest right every uh neither none of the delegates nor the matcher is going to be able to

see the actual data x right they cannot retrieve it and of course by the discrete logarithm as well so that's about the delegated psi um just to kind of close this for a second let's let's review the actual protocol in steps so the setup is really that the delegates sample uh sort of a ki right a share the participant then computes the the blinding the blinded prf generates the secret shares and sends uh the the shares to the delegates and then the delegates are going to add sort of the the shares and remove the r shares this is all happens as part of the upload right what we call the upload and that's sort of one message interaction from the

side of the participant right if you're if you're a customer using this you can kind of go offline after this happens and then you're going to have the matching right the matching is going to happen at the matcher and then maybe i could have added a fourth here where it's sort of download where when the customer is signing in again logging in again there the results from the matches and the intersection are going to be back sent back to the uh customer uh and it's seen it's also it's almost seemingly right sorry um so now we have these matches right like the the the matcher has ability to compute matches and maybe i'll say i'll say one one thing here and that is that uh it is

clear i'm sure you've all noticed that the matcher has some leakage of this data right um and that's because uh you know it can see for example the the actual size of the intersections and other uh metadata like that but um it's in some settings it's not critical so i'm also happy to talk about that um but now we have these matches and as we said now we want to do something with this data right so how do we aggregate data well let's use homomorphic encryption but let's see how we can use it so for those that are not really sort of familiar with with homomorphic encryption this is really like the the kind of a whole concept of homomorphic encryption in this table i

really like to to think about it because essentially you whatever wherever you start right you really start in m but you no matter what path you take here right all the way through the encryption or from here you're gonna end up getting f m so the idea is that this layer is where the uh sort of the party lives and then this layer is where a server right a delegated server lives and the idea is that you know i would encrypt m using some uh homomorphic encryption function under some maybe my private key and instead of computing f by myself because it's potentially a intensive function computation then the server would

compute this evaluation function based on f uh it's actually based on sort of circuit evaluation and would essentially get the encryption of f of m right so uh you know the the equation really is that the evaluation of the encryption of m is equal to the encryption of f of m and once this is sent to the uh client or the customer then they can decrypt and get fm back but now the this is really for for sort of a one client and one server right but we are talking about several clients so how does that work uh in an application well let's add that client right so we have

sort of one message from from alice uh who's going to compute some some ciphertext and another message m2 from bob right the key point here to observe is that they both need to encrypt their messages based on the same using the same public key because you know if not you're not going to get uh you're not gonna the the aggregator uh party is not going to be able the server is not going to be able to add those ciphertext unless you're using something in fancier like multi-key homomorphic encryption which is less practical today uh but yeah that's that's a whole different uh conversation we can have

um and then when when you know you encrypt under the pk the you send these these ciphertexts so c1 pk and c2pk to some server and then the server is going to evaluate based on some function right and and the idea is that you want to get sort of the encryption of the function of the messages uh by by computing this evaluation circuit and what happens now is that okay well this encryption is actually under uh pk right so maybe i i definitely should add here pk but now the question really is who has the sk the secret key corresponding to this public key and if you say okay these two parties

have sk then okay so why did they even encrypt it like if they have a common secret could they have not done something by themselves um or what if you know they encrypt different things and and now you say okay maybe you would have wanted that every pairwise party has a common key but what if you need to aggregate things from three different sources so the key here is that this can get complicated very fast and the best thing to do is to use this kind of re-encryption method where this aggregator is going to actually have the secret key and and yeah if that triggered a bell because uh it can be insecure i'll say that in a second but assume for a second that this

is a server and it has the secret key um then in some sense uh what what can happen is that this this part is going to re-encrypt the ciphertex c to that is encrypted under pk to be encrypted under pk1 and pk2 where now pk1 is the public key associated to a secret that is unique to this uh party and this is also as sk2 is a secret unique to bob right and of course as i said right if if uh if the owner of sk right if the aggregator has sk it can decrypt all the values which we don't want so what we do again we use the same model as before we reuse the flow and architecture of the delegates

and we distribute the secret key so how does that look like well i'm going to sort of say a few things about the actual scheme that we use uh i won't get into the concrete math i did put the pictures there but because i think it can be interesting to some um but before we see the whole protocol i want to share these insights so the idea here is that again you're going to have a distributed key generation right where essentially each delegate is going to generate a different ski okay individually right and then there is sort of a common public key right ckp or cpk sorry um that is going to be generated but uh in in sort of a single

uh for a single message right so there is not even interaction between the delegates there it's a one message uh that is sent to a coordinator and it's securely uh generated and then each participant is going to input their data x i and you want to essentially have a collective output right of f of x1 to xn and you can see here the functions right where you're going to encrypt using the common key um and uh and then you're going to sort of evaluate all of these be able to evaluate these and have the the output be the encryption of these things and of course if you want to decrypt you need the secret keys but what we said right is that we're

going to want to re-encrypt this cipher text c prime to the probably keys or the secret keys of each individual participant that whose data was aggregated okay and the way we do that is by by using this um this sort of re-encryption or key switching method um so uh um again i'll say the following which is that we don't want the delegates to be able to decrypt right so the key switching protocol uh sort of actually happens sorry so this is actually the um generation of the public key the common

public key just to show that it is done in a single uh rounds where each party samples some randomness and compute something and then this is publicly aggregated and what happens is that um we can use this idea of collective key switching where essentially if you have right some ciphertext you want to essentially compute um the partial decryption or the decryption of this ciphertext and at the same time encrypted under a different public key pk right but the key here is that we want this to happen

purely without the delegates or without the party that does the collective key switching without them seeing the value under the ciphertext okay and this is by the way the paper sorry about that this is the paper that um yeah okay that i'll share the the slides at some point so what does this key switching look like uh without getting into the details because again the homomorphic encryption scheme we use is the bfv uh scheme if you're any familiarity with it but it's based on lattices and it's definitely not easy to start explaining lattices at least not in a short time and the idea here is that again you have some

public key pk prime and some cipher text encrypted under pk and each party that owns a secret key is going to compute these values this h0i and h1i and no need to think about the math explicitly but just to know to see that it's actually again a one round right so the parties are using their own secrets right as a private input si this is a private input the rest is all public inputs right and what's going to be outputted is the ciphertext encrypted under pk prime and as you see the um the the parties the delegates computing this key switching

do not know the secret associated to pk prime right because in order to do public encryption and encrypt you don't need to know a secret so that should be kept as a heuristic here and so what happens is that they compute these two elements and then they're going to output those so that there's a public aggregation phase that is going to output the new cipher text sorry about that um so you can see that that again this is sort of happens in one round um and what you get at the end is this new cipher text and now when you encrypt these you can send these to the different parties okay so maybe this couple of last slides were a little bit uh heavy or intensive uh but let's kind of put it all together okay

so again what's what happens during this this homomorphic encryption uh flow is the following at the beginning you have a setup where essentially you have um the delegate keys okay each one of the delegates generates a different secret right individually independently sk1 to skm and then uh let's say the coordinator again we can overload the proxy uh in the network is going to do the aggregation of the uh public key okay and again it's not it's public operation right so that can be done and it's secure and then what's going to happen that um we're going to get

say alice bob and charlie uh but let's just focus on alison bob for a second that they're going to each encrypt the value a and b okay they're going to encrypt it again using their the public key of the delegates pkd right the common public key so you're going to they're going to send the cipher text to the coordinator and then here the the this is where sort of the psi flow and the homomorphic encryption flow come together where after there is a match right the matcher or the coordinator is going to aggregate the values associated with those matches in the specific way that it's defined right using the specific function

it could be additions including multiplications it could be sorting it could be other kinds of things and um they're going to the matcher is going to add the ciphertext right again it's a homomorphic uh scheme and these are going to be then sent to the delegates right but now the key here is that for example um once alice say signs in again into the system the system is going to generate the pair route locally she's going to generate a pair of keys a new pair of keys ski and pki and then these keys are going to be sent again as well to the matcher who then is going

to send to the delegates to each delegate the ciphertext the aggregate ciphertextc and the public key pka of alice what happens is that each delegate this now is not in series right last time we saw in in this psi setting that there is an in-series protocol in some sense and in here it's actually in parallel so each delegate is going to have sort of a partial decryption right they're going to compute their h values right which are these h values i just abbreviated them to to have to one but it's these exact values and each one of them is going to do the same and send these h values to the coordinator

and then the coordinator as you can see here in blue is going to do the aggregate step right if you see here this aggregate step of adding the different values and outputting the new cipher text right that's what the coordinator is going to end up doing and the nice thing about this is that throughout all of this process neither the matcher nor the delegates actually saw or got to be able to see the underlying values not a not b and not a plus b right and then once this process is done the matcher is going to send or the coordinator is going to send this uh newly encrypted ciphertext

c prime a right which is the re-encryption of being ciphertext c under the public key of alice and then alice finally just takes the secret key and decrypts it and gets the actual result of a and b right uh in this case the function is uh just addition to simplify it but again this could be any function and it would still give him give her uh the actual result of the function so and again the the next nice thing is that all of this is actually uh secure as long as one delegate is honest right so making sure that the delegates are distributed and then you get the full security

is uh is important and you can now see how sort of the psi comes together with the homomorphic encryption in order to get some matches and then compute on those matches right um and just to kind of wrap up i know i'm a little bit over time but hopefully hopefully we'll have time for all the q a we are of course thinking about these sort of two next steps i would say um one of them is sort of like the idea of proving correctness right i've talked to you about security and and that's amazing because you know that uh no matter what happens neither the matcher nor the delegates will be able to get the data so that's full security on the on the privacy of

the data but then you get that um if the delegates don't one of the delegates even doesn't compute the the exponentiation correctly with the right key or you know switches key in the middle of the process or the matcher just decides to leave aside some of the matches things like this of course that is not detectable at this point by the participant and that could be a problem right in some settings in some contexts so correctness is important and the way we want to solve that is actually by using zero knowledge uh zero knowledge proofs which you know in as in the zk summit uh event you know mostly talks about zero knowledge uh and as much as my talk wasn't exactly

around zero knowledge this is definitely an important component right so this idea of putting together a lot of different uh privacy enhancing cryptographic techniques is important and essentially if we think about what would the zero knowledge look like well we we could do sort of we would need to prove two two main things right one is that at the matcher the matches are really done correctly meaning that there is no false negatives or positives right um and there are also several techniques for that and the second point to be proven is around of course the integrity of data right because the data that is input by the participant is different from the data that is handled by the matcher we need to prove

that the conversion was done correctly right so essentially we need to prove that the delegates computations was done according to you know the algorithm based on some pre-committed keys right key shares um and uh this is uh this is definitely an interesting direction uh there are many ways of actually instantiating this proof you could use recursive composition or you could use uh you know multi-prover uh systems um and uh you know it's a very interesting direction and of course we also have like more engineering problems and challenges like data normalization because you know different resources and databases will definitely not have the

same kind of data and you know if you have a name with capitals letters or or you know numbers with dashes or not things like this are always important to keep in mind and also ease of deployment right when when we're talking about combining so many cryptographic schemes one needs to really be careful about around the security and also around sort of what aspects can be automated and whatnot right because here we want to make sure that all the encryption and all the decryption happens locally say on the browser or uh actually local on the computer right um and uh this is really this is really it um you know there's of course a lot of more to talk and to share but um i'm happy to to take some questions

so thank you thank you again for for listening um yep hey hey okay there's some great questions in the chat it's possible some of them have already been answered so if that's the case maybe we can move quickly through them like for example robert asked but maybe a little bit of a way ago in the production what real world entity is represented by a delegated and i think he meant delegated psi protocol or delegated obvious i know that you had on the slide at the time um yeah i think i think here yeah i think that i get the end the question which is uh who represents the delegates or who holds the delegates and the key here is

that they need to be distributed right different amazon accounts aws or google cloud and that different uh you know companies different organizations and of course this is a challenge that we need to keep in mind uh we are sort of working through that um but um that's that's sort of the the main idea right that the delegates really need to be distributed for this to be secure the next one is do all delegates need to be online or does this approach support an nfm scheme to all the delegates need to be online or uh so the next version of this is is definitely a kind of a threshold version so far we're we're really only doing uh

you know full delegate online if you wish i mean we know we actually know how to do uh threshold but we don't we didn't implement it yet because it's uh just a little bit more complicated and you know we have product product priorities uh do delegates refresh their prf keys per psi instance the delegate so um yes here i'll just sort of make a translation where by psi instance we mean essentially all the types of data or all the data that needs to be sort of matched together right we do allow for sort of adding more data

you know at a later time and that's that's a an interesting feature that we have we we have some some some methods there but um we don't sort of we could also say just refresh the the keys for every time some some data is uploaded inside of quote unquote and instance or what we call like a topic essentially but you need to have uh some some permit permit permanency over those keys in order to be able to do the matches right akash asked doesn't the coordinator have to be honest if it's doing the aggregation of the

delegate secret keys yes so this comes back to correctness um it uh it has to be uh honest and you know uh the only way to ensure that in this current setting is would be to use something like zero knowledge or at least just a proof right it doesn't necessarily have to be zero knowledge because the computation is not secret um but uh there is there is a component here of as i said like correctness is important and you know we're working through that um but you know it comes at the expense of of other things at this point what about the matcher being dishonest is the he psi i think this is the same question

uh okay coordinator here i mean yeah because essentially you know one is about the aggregation of the secret keys to to generate the correct public key uh but the other one is about uh sort of uh actually doing the computation on the he or the psi again like the matcher at this point is a trusted entity but it's not uh but but even if it's malicious it cannot be um it cannot sort of get the actual data of the participants cool um hubert asked what circuit depth for the he function have you tested as being practical so we've been working

mostly with like like really large amount of additions uh and some multiplications maybe like averages and things like this so it's not like we have a large depth um we are aware that maybe using like a fully homomorphic encryption scheme is a bit of an overkill if that's sort of the only computations that we have but there is definitely a scenario where uh you know users are going to start asking for a lot more complex stuff so um you know we're testing some things i just they're not ready to be shared at this point not not optimized enough okay victor was asking is it possible that the court

is it possible that the coordinator exclude individual records i guess this kind of goes back to that dishonest question right so here this is exactly what i meant sort of in the no false negatives or positives right because what this means is that we want to make sure that the matcher um exactly that does not leave any matches out and does not add any matches that are not supposed to be matches right because if if i'm if i'm a customer and i just get some matches i need to trust that those are the actual matches um i if especially if i'm not interacting with my counterparty right

um victor actually clarified this question saying can the coordinator distinguish individual records or all are all the records bundled and encrypted together um well they all look sort of random to the matcher so they he i mean the matcher can uh distinguish in the sense of they know that two records are different it just doesn't know what the delta is it doesn't know anything about it yeah it's just sort of random strings all the way right it just they the matcher does get some leakage in the sense of it knows exactly what two match what two records match um but uh yeah and i mean it also knows you know

what set of hashes belong to which party because he's also also acting as the proxy so you know next uh version i guess could also be the separating between what we call the match or what we call the proxy and what we call the coordinator or something like this i hope that clarifies it victor maddie asked do delegates execute the same partial decryption algorithm independent of their secret keys or is it to be run under their own secret keys or their own secret keys so here i think what you mean is this uh partial decryption um and um the answer i mean if i understand

the question correctly but please do to correct me mad if i'm if i'm wrong is yes it's independent i mean each delegate has their own secret key sk1 esk2 and so on and the partial decryption that they do happens completely independent without any uh sort of interaction with the other delegates and that's the nice thing that there is like a one message to like a coordinator or uh something like this that will aggregate these h values uh from each of the delegates right we we always try to uh when designing this protocol we always try to kind of have a one message interaction in the different parts where interaction is needed because of the distribution of the secret keys

and shares duran asked what psi construction does he support i'm not sure what you mean by that i mean we sort of built our own psi like based on several components from different psi papers and uh the the in some sense what i explained here was that there is like two flows really one is the psi flow and the other one is the homomorphic encryption flow so they can really just be to put together as long as you have this ability of uh you know we use the same architecture

just in a different uh order let's say first uh you know the psi happens first so the first flow for psi is that the participants talk to the delegates on the upload and when i say talk i mean like sort of quotation marks talk to the delegates on the upload phase but then after they've gone offline when they go online again and they want to get the download query then uh that's when they interact again with the delegates in order to get the homomorphic encryption uh done right um so i hope that clarifies that but uh there is no sort of specific construction and in the hc

like it's and i think we have a great kind of last question here is this operational or currently in development is it live so i will say both uh you can actually go today uh and uh try this out using your wiz using an excel sheet uh if you go to like microsoft's 365 uh and and go into the excel there you can actually download the credit plugin or add-on i don't remember what they call it but and you can use this and try it i don't think that we implemented there the homework encryption but uh going back to the answer like the

question it's operational in the sense that we are working with several customers to sort of work through through their use cases and and you know we're running uh real data through this uh but it's not in in deployment yet in the proper sense of the word uh you know where you just go into the website and pay with a credit card and use it or something like this i mean maybe maybe after this chat if you want to put any links or something into the chat that might actually be useful for any documentation or any any way for people to start accessing it yeah absolutely yeah i would love it all right so thank you so much daniel

thanks for uh doing this talk and your first talk at the zk summit very cool it's a crossover episode um all right so uh to everyone else we will cut the stream here and we'll be back here in about eight minutes for alex from matter labs talk cool see you soon