 is about topology hiding computation for networks with unknown delays and it's with my many co-authors Rio Chenta, Wally, Tal and Daniel. This is about multi-party computation or MPC where a bunch of parties some of which may be corrupted want to run some protocol which is almost as good as this trusted third party who just takes the inputs and distributes the outputs to the parties. So what this means is that protocol should reveal nothing about the inputs except what can be computed from the output of the function and now what one can ask the question what about other aspects that the protocol could leak for example if you think of broadcast what about the sender of the message or the receiver maybe and topology hiding computation looks at one particular such aspect which is the network topology so parties communicate via complete network and they want to hide the communication graph and one justification for this could be for example social network where parties communicate with their friends and for example via Facebook and they don't want to reveal the friends of friends of friends of friends who their friends are so what about topology hiding computation we have a bunch of protocols already they look at different types of adversaries different classes of graphs and different setup assumptions and one disclaimer is that topology hiding computation always looks at looks at setup that is reusable and independent of the graph not to trivialize the problem and this is the only setup I will talk about here so these first four protocols consider passive adversaries the first two are only efficient for graphs with small diameter and the third works for cycles and trees and finally we have a protocol for all graphs then we look at more powerful adversaries for example a fail stop adversary who can crash parties and here we have these two protocols that both work for all graphs the first one requires a hardware setup so secure hardware boxes but one implicit assumption behind all of these protocols is a network assumption they all require that the network is fully synchronous meaning that the parties are synchronized and there is a known upper bound on message delivery time and there it's guaranteed that a message which is sent will be delivered before that upper bound but this is not how the real world works right the world is not synchronous messages are delayed parties are desynchronized and so in this work we ask what happens to topology hiding computation or THC for sure if we don't assume a synchronous network and sadly our first result is impossibility and we prove that in in a model where as usual for asynchronous NPC the adversary is allowed to schedule messages topology hiding computation is impossible and in fact we rule out quite a lot of settings because we only assume that we assume that parties are already synchronized a message between honest parties are delivered synchronously so there is a known upper bound but the adversary can schedule messages between corrupted parties and their neighbors and this already rules out THC so then we propose a model where the topology hiding computation is possible and here the messages are delivered with arbitrary random delays but independent of the adversary still parties do have synchronized clocks and we thought this was a milder assumption than this upper bound on the network delivery in particular it allows protocols that run as fast as the network the actual network not the upper bound of course we propose protocols for our model one for cycles and trees under standard assumptions and the second one for all graphs but we assume hardware so here are our results in the table we proposed this new model with unknown unbounded delays we consider passive adversaries and we have one protocol for cycles and then it can be extended to trees this is the same setting as here and one protocol and here we assume as some pki like setup and the second protocol works for all graphs but we assume hardware just like bbmm here so in this talk i want to focus on our model and the protocol for cycles for the impossibility result and the hardware protocol please see the paper i will just say shortly what what hardware means it means that every party has a hardware box is on and these boxes are preset with shared keys and they perform some secure computation on the shared using this shared key okay so what model um we start with the standard the parties communicate via this network functionality which has a graph inside and delivers messages along the edges and you can think of these channels implemented by this functionality as really secure channels so the adversary doesn't even know whether the channel exists or not whether the message was sent or not only the messages to corrupted parties are are sent to the adversary and then in the ideal world we replace this network functionality by the simulator who receives the output of the function and he's supposed to emulate the messages um sent to corrupted parties of course he learns the neighbors of corrupted parties and the graph if you're wondering is inputted by the environment directly at the beginning of the computation so how do we go about defining what um what it means to deliver messages with unknown unbounded delays random so first of all we need an ocean of delay and we need an ocean of time and this is what we do we add this clock functionality which synchronizes parties as I said parties will be synchronized in our model um this is the more or less standard clock functionality by cats at all and it measures um what we would call atomic clock ticks so think of it as as the smallest measurable amount of time for example one nanosecond and the idea is that protocols will run in rounds and around will last many clock ticks so a protocol will do something only every um are clock ticks where are is sufficiently large to account for the computation time so now that we have clocks uh we can define to deliver messages with random delays and this is done by enhancing the um the network functionality graph uh the network functionality with delay distributions so now every edge in the graph has a label which is a delay distribution and when the message is sent uh the functionality samples um a delay from this distribution and delivers the message after that many clock ticks so what this means is that there is no um upper bound on the on the delay the delays are completely arbitrary and they are inputted by the environment at the beginning of the execution together with the communication graph but we do not consider um infinite delays meaning that a message will be delivered eventually uh so we have we have channels with eventual delivery so that's almost it but as I said a nice feature of asynchronous protocols is that um protocols run as fast as the actual network and we would like to keep it in our model so what this means is that the protocol running time will actually depend somehow on these delays so we need to leak something to the simulator to to um to simulate the running time of the protocol and this will respond roughly to the sum of the delays of in the network um yeah so so we don't leak the actual graph but the sum of the delays okay so this is our model and now let's go to the protocol for cycles so first I wanted to tell you why some um simple solutions to uh transform any old synchronous protocol into this setting don't work so imagine we have some sort of protocol doesn't matter what it does yet and um in round i a party is supposed to receive the message mi but it doesn't so first thing that can happen in our model is that messages arrive late what does the party do so first solution maybe we just abort so the party will abort uh emulate the crash and the other parties are supposed to run a fail stop protocol um the problem with this is that fail stop protocols so protocols secure against fail stop adversaries uh have security with abort but in our model we have actually eventual delivery of messages so we would like to um have also eventual delivery of output so we don't want this a weaker guarantee of security with abort which is inherent in failed protocols also another caveat is that they leak as a non-negligible small amount of information about the network the solution would be to send a dummy message but this will cause the messages to clog in the network so we we now generate a lot of messages and then we have the worst that there are too many messages arriving together we cannot some of them because that destroys correctness and unfortunately in topology hiding computation if we destroy correctness we usually also leak something about topology the way we destroy the correctness um we cannot all of them because that reveals something about the distribution on the edge for example if now this party sends all of his messages then this party probably learns something about how many messages he got and then something about this edge which leaks the topology so these are the problems we are facing and here is our protocol for this simpler setting so we deal with all of this um in the hardware protocol using the hardware and here is our protocol in the standard model for the four cycles um so we will start with uh with a synchronous protocol and we won't construct mpc directly but we will construct broadcast and as we know we can compile any broadcast protocol into um into an into any mpc protocol and we will focus on bit broadcast to keep it even simpler and then of course you can run it many times to broadcast many bits and yeah we start with the synchronous so now we start with the synchronous broadcast on um bit broadcast on cycles and the goal is to construct uh broadcast topology broadcast on cycles for our model we have a bunch of parties on the cycle we have a sender um with a bit and what will the protocol do um consider for example this party down here who wants to receive the output so in the first round generate an ephemeral keeper start a secret key to himself and send an encryption of zero under the public key and this notation here will denote that he sends both the cipher text and the public key so this protocol is is based on on akavya moran it's it's very close to and akavya lavin moran the second to the last two protocols for um for passive adversaries okay so now in the second round the next party gets the cipher text encrypted under bit one and thus is to generate an ephemeral keeper on his own store the secret key to himself and send an encryption of uh of zero but under the product key so now the public key is living a group um and one can compute this product public key and transform a cipher text from encrypted under one public key to encrypted under the product public key and you can think of algamal encryption which achieves this key homomorphic property uh or you can just think that this bit is now protected by both keys so next in the next round we got to the center the center will do the same but um in addition he replaces the cipher text by the encryption of his bit so now we have encryption of the bit going to the next party who adds his key to the product key and finally after four rounds we have five parties we counted four rounds um we traversed the whole cycle so now for sure the the cipher text contains the bit um encrypted under the product public key of all parties but the last one but the last one doesn't need to include and then we start what we call the backward phase where parties delete their keys from the product key so in round one those messages the messages send back the party deletes um his key next deletes next key after we get to this first party you can decrypt and get so to get topology hiding broadcast we run this in parallel um all parties run this in parallel to receive their bits in both directions the center also acts as the receiver to hide who he is and one can extend to all graphs using random walks this will not be the case for our protocol um yeah so what are the problems with this so the first problem with this protocol if we go to our setting is that we don't know when to start the backward phase so for this first variant we will consider network with constant delays for simplicity then I will tell you how to deal with variable delays but for now let's consider constant delays uh unknown so still we cannot run this this first protocol and here the first problem is that we don't know when to start the backward phase so before we counted how many runs um the the how many runs rounds the protocol runs and after n rounds uh with n parties we knew that every party saw the cipher text and we could go back now we don't have this guarantee we don't know the upper bound on the full delay in the network on the on the delay in the network so we deal so we deal with this by not doing the backward phase only do the forward phase but we require setup perhaps not surprisingly the setup is the product public key so now every party has a secret key and the product public key of all public keys in the network and one difference here is that these keys are not ephemeral they will be reusable so how we modify the first protocol well at the start of the computation the party sends an encryption of zero but under the product public key and then every round so every clock ticks the next party will send something so maybe he didn't receive the cipher text yet so he will send an encryption of some garbage value doesn't matter under the product public key and at some point he will receive the first cipher text and since the first party sent the encryption of zero every round now after receiving the first cipher text the party will the next party receives um one cipher text cipher text per round so we rule out many of these problems of of random delays so what does the party do um as usual he deletes his key from the product sends it on the sender additionally adds his bit and after everybody deletes his key from the product key we get to the the original party and after the sum of all delays in the network the party gets the encryption of the bit under his key and gets the bit so here is the next problem with this and the problem is that the partial public keys send around actually linking for so here is the picture again and what if the party is corrupted so remember that this notation actually meant that we also send the public we make it public and the party can watch how long the public key sent by this guy is equal to the actual product public key and this means that this party actually hasn't received the cipher text yet and after the key changes uh he knows exactly after the public key changes this means that the guy already received the cipher text and this reveals exactly the delay on this edge which is not topology hiding so to deal with this now we won't send the public key around and we have a special encryption scheme with an algorithm that supports and changing an encryption of a 0 into encryption of a 1 without the public key and in the paper we define abstract properties of this encryption scheme that we need but directly an implementation based on Divi Helman so the the keys are Divi Helman keys and the group operation that we will consider is multiplication in the exponent and we don't compute it don't worry encrypt a bit under a public key we generate this Divi Helman key with a random value so here the second component of the cipher text is always the Divi Helman key and the first component this is perhaps a change it's either G to the R or G to the R squared depending on the bit now to decrypt we of course shave off the the secret key from the second component so this is done here and check whether it matches the first component or whether the square of it matches the first component and otherwise we output bottom so we already have some level of robustness in this decryption scheme in this encryption scheme to change a bit to change an encryption of 0 into encryption of 1 of course if your bit is 0 then you don't have to do anything but to change is we just square the first component this is quite easy we also need re-randomization which is obvious here and partial decryption where we just shave off this the secret key from the second component and this is to delete your part of the key from the product key so how will we use it in the protocol when the party receives a cipher text C and D he first tries to decrypt if it decrypts he outputs bottom if not sorry if he decrypts he outputs the bit if so this means that the cycle is traversed and this was his actual actual traversal it carries his bit otherwise he partially decrypts so he shaves off his his part from the product key re-randomizes and sends and additionally if the bit is 1 changes encryption of 0 into encryption of 1 by squaring the first component and this works this is this works for constant now how to account for variable delays and here we we make some assumptions so the first assumption is that each party can approximate somehow his distribution on on his edges not on the network but the edges that he can see he can approximate somehow and the messages are sent are that are sent are clock ticks apart so every round are delayed independently so not every clock tick this would not make sense this assumption but every round if a message is sent messages are sent two rounds apart one round apart then then they're independent and the idea is to simply make the delays constant by repeating message sends over many many rounds so this is how it looks in picture for example if consider the first round we choose this parameter t based on this distribution this will somehow corresponds to the medium of this distribution and at the beginning of the protocol the left party so we just consider one edge we want to make this delay constant and at the beginning of the execution the party generates his message for the start of the of the protocol sends it together with the index one and in the next round so after our clock ticks he will generate the second message and send the second message and the first message again so he sends two messages this is done until t rounds and in round number t he sends t messages so the first one the second one the third one and so on up to the teeth one and this means that the first message was sent t times over t rounds and t is chosen such that with high probability at least one of these messages arrive after t rounds so after t rounds we know that some of these messages may be more of this of these first messages arrived at the second party and then the second party can actually take this message so he ignores the message one before before t rounds and in round t he will process it and send it on as as if received we can stop sending them message number one but in the next round we send the t plus one message and this means that the delay is is basically constant but t times longer and this is our protocol now to summarize we proved that the fully asynchronous fully asynchronous topology hiding computation is impossible we propose a model where it is possible and the model is still much closer to the real world than the fully synchronous setting so we have a random unknown unbounded delays we have one protocol for cycles and this can be extended to trees this is what i showed you and we have a protocol for all graphs that assume secure hardware um and open problems there are actually a lot of open problems in topology hiding computation one immediate problem would be to to have a topology hiding computation with a non-delays for all graphs but without hardware so this is the same situation as for a defense of adversary where we had this first protocol with hardware and then the second paper removed this assumption um we could do the same perhaps for topology hiding computation here with a non-delays we could consider stronger adversaries for example fail stop i think an active adversary is still a widely open problem for topology hiding computation and then maybe the last question would be to remove the assumption of synchronized clocks from our model and propose protocols that are also secure without synchronization um there is also kind of it's also a bit hard to define because that adversary doesn't know the communication network so who schedules messages between honest parties and this is a bit tricky so i encourage you to to think about this too so thank you and