Topology-Hiding Computation for Networks with Unknown Delays

Abstract

Topology-Hiding Computation (THC) allows a set of parties to securely compute a function over an incomplete network without revealing information on the network topology. Since its introduction in TCC’15 by Moran et al., the research on THC has focused on reducing the communication complexity, allowing larger graph classes, and tolerating stronger corruption types.

All of these results consider a fully synchronous model with a known upper bound on the maximal delay of all communication channels. Unfortunately, in any realistic setting this bound has to be extremely large, which makes all fully synchronous protocols inefficient. In the literature on multi-party computation, this is solved by considering the fully asynchronous model. However, THC is unachievable in this model (and even hard to define), leaving even the definition of a meaningful model as an open problem.

The contributions of this paper are threefold. First, we introduce a meaningful model of unknown and random communication delays for which THC is both definable and achievable. The probability distributions of the delays can be arbitrary for each channel, but one needs to make the (necessary) assumption that the delays are independent. The existing fully-synchronous THC protocols do not work in this setting and would, in particular, leak information about the topology. Second, in the model with trusted stateless hardware boxes introduced at Eurocrypt’18 by Ball et al., we present a THC protocol that works for any graph class. Third, we explore what is achievable in the standard model without trusted hardware and present a THC protocol for specific graph types (cycles and trees) secure under the DDH assumption. The speed of all protocols scales with the actual (unknown) delay times, in contrast to all previously known THC protocols whose speed is determined by the assumed upper bound on the network delay.

R. LaVigne—This material is based upon work supported by the National Science Foundation Graduate Research Fellowship under Grant No. 1122374. Any opinion, findings, and conclusions or recommendations expressed in this material are those of the authors(s) and do not necessarily reflect the views of the National Science Foundation. Research supported in part by NSF/BSF grant no. 1350619, an MIT-IBM grant, and a DARPA Young Faculty Award.

T. Moran—Supported in part by ISF grant no. 1790/13 and by the Bar-Ilan Cyber-center.

M. Mularczyk—Research supported by the Zurich Information Security and Privacy Center (ZISC).

D. Tschudi—Work was done while author was at Aarhus University, supported by advanced ERC grant MPCPRO.

1 Introduction

In the wake of GDPR and other privacy laws, companies need ways to process data in a way such that the trust is distributed among several parties. A fundamental solution to this problem is secure multiparty computation. Here, one commonly assumes that all parties have pairwise communication channels. In contrast, for many real-world scenarios, the communication network is not complete, and parties can only communicate with a subset of other parties. A natural question is whether a set of parties can successfully perform a joint computation over an incomplete communication network while revealing no information about the network topology.

The problem of topology-hiding computation (THC) was introduced by Moran et al. [MOR15], who showed that THC is possible in the setting with passive corruptions and graphs with logarithmic diameter. Further solutions improve the communication efficiency [HMTZ16] or allow for larger classes of graphs [AM17, ALM17]. Recent results [BBMM18, LLM+18] even provide THC for fail-stop or semi-malicious adversaries (although at the price of leaking some small amount of information about the topology).

However, all those results consider the fully synchronous model, where a protocol proceeds in rounds. This model makes two assumptions: first, the parties have access to synchronized clocks, and second, every message is guaranteed to be delivered within one round. While the first assumption is reasonable in practice, as nowadays computers usually stay synchronized with milliseconds of variation, the second assumption makes protocols inherently impractical. This is because the running time of a protocol is always counted in the number of rounds, and the round length must be chosen based on the most pessimistic bound on the message delivery time. For concreteness, consider a network where most of the time messages are delivered within milliseconds, but one of the connections, once in a while, may slow down to a couple of hours. In this case, a round would have to take a couple of hours.

1.1 Contributions

This motivates the goal of this work, which is to construct THC protocols for more realistic settings, where messages are not guaranteed to be delivered within a fixed time bound.

Model. A natural starting point would be to consider the strongest possible adversary, i.e. one who fully controls message delivery (this is the standard setting considered by asynchronous MPC, e.g. [BOCG93, Can01]). First, note that this standard model is not well suited for our setting, since in order to decide when messages are delivered, the adversary must know the network, which we attempt to hide. The next logical step is to consider a model where the adversary can only interfere with delays between parties he controls, but unfortunately, even this grants the adversary too much power. In fact, we prove in Appendix A that it is impossible to get a topology-hiding broadcast in this model.

This forces us to define a slightly weaker model. We call it the Probabilistic Unknown Delay Model and we formally define it in Sect. 2. In this model the messages are delayed independently of the adversary, but different connections have different, unbounded probabilistic delays. This means that we throw off the assumption that makes the synchronous protocols impractical. Still, parties have access to synchronized clocks.

Protocols. We remark that it is not easy to modify synchronous THC protocols (even those tolerating fail-stop adversaries) to remain secure in the Probabilistic Unknown Delay Model. For example, consider the standard technique of letting each party attach to each message a round number r, and then wait until it receives all round-r messages before proceeding to the next round. This seems to inherently leak the topology, as the time at which a party receives a message for round r reveals information about the neighborhood of the sender (e.g., that it contains an edge with very long delays).

This forces us to develop new techniques, which result in three new protocols, secure in the Probabilistic Unknown Delay Model against any number of passive corruptions. We require a setup, but this setup is independent of the network topology (it only depends on the number of parties), and it can be used to run multiple instances of the protocols, with different communication graphs.

Our first two protocols (Sect. 3) implement topology-hiding broadcast (any functionality can then be realized using standard techniques, by executing a sequence of broadcasts). The protocols are based on standard assumptions, but can only be used in limited classes of graphs (the same ones as in [AM17]): cycles and trees, respectively.¹

Furthermore, observe that the running time of a protocol could itself leak information about the topology. Indeed, this issue seems very difficult to overcome, since, intuitively, making the running time fully independent of the graph delays conflicts with our goal to design protocols that run as fast as the actual network. We deal with this by making the running time of our protocols depend only on the sum of all the delays in the network.

Then, in Sect. 4, we introduce a protocol that implements any functionality, works on arbitrary connected graphs, and its running time corresponds to (one sample of) the sum of all delays. On the other hand, we assume stateless secure hardware. Intuitively, a hardware box is a stateless program with an embedded secret key (the same for all parties). This assumption was introduced in [BBMM18] in order to deal with fail-stop adversaries in THC. Similar assumptions have also been considered before, for example, stateless tamper-proof tokens [CGS08, GIS+10, CKS+14]², or honestly-generated secure hardware [HMQU05, CT10].

While secure hardware is a very strong assumption, the paradigm of constructing protocols with the help of a hardware oracle and then replacing the hardware oracle by more standard assumptions is common in the literature (see for example the secure hardware box assumption for the case of synchronous topology-hiding computation (with known upper bounds on the delays) for fail-stop adversaries [BBMM18], which was later relaxed to standard assumptions [LLM+18], or the Signature Card assumption for proofs-carrying-data schemes [CT10]). We hope that the techniques presented in this paper can be useful to construct protocols in more standard models.

1.2 Related Work

Topology-hiding computation was introduced by Moran et al. in [MOR15]. The authors propose a broadcast protocol tolerating any number of passive corruptions. The construction uses a series of nested multi-party computations, in which each node is emulated by its neighbors. This broadcast protocol can then be used to achieve topology-hiding MPC using standard techniques to transform broadcast channels into secure point-to-point channels. In [HMTZ16], the authors provide a more efficient construction based on the DDH assumption. However, both results are only feasible for graphs with logarithmic diameter. Topology-hiding communication for certain classes of graphs with large diameter was described in [AM17]. This result was finally extended to arbitrary (connected) graphs in [ALM17]. These results were extended to the fail-stop setting in [BBMM18] based on stateless secure hardware, and [LLM+18] based on standard assumptions. All of the results mentioned above are in the cryptographic setting. Moreover, all results are stated in the synchronous communication model with known upper bounds on the delays.

In the information-theoretic setting, the main result is negative [HJ07]: any topology-hiding MPC protocol inherently leaks information about the network graph. This work also shows that if the routing table is leaked, one can construct an MPC protocol which leaks no additional information.

2 The Probabilistic Unknown Delay Model

At a high level, we assume loosely synchronized clocks, which allow the parties to proceed in rounds. However, we do not assume that the messages are always delivered within one round. Rather, we model channels that have delays drawn from some distributions each time a message is sent along (a different distribution for each channel). These delays are a property of the network. As already mentioned, this allows to achieve a significant speedup, comparable to that of asynchronous protocols and impossible in the fully synchronous model.

2.1 Impossibility of Stronger Models

Common models for asynchronous communication [BOCG93, Can01] consider a worst-case scenario and give the adversary the power to schedule the messages. By scheduling the messages, the adversary automatically learns which parties are communicating. As a consequence, it is unavoidable that the adversary learns the topology of the communication graph, which we want to hide.

A natural definition, then, would be to give to the adversary control over scheduling on channels from his corrupted parties. However, any reasonable model in which the adversary has the ability to delay messages for an unbounded amount of time allows him to learn something about the topology of the graph. In essence, a very long delay from a party behaves almost like an abort, and an adversary can exploit this much like a fail-stop adversary in the impossibility result of [MOR15]. We formally prove this in a very weak adversarial model in Appendix A.

Since delays cannot depend on the adversary without leaking topology, delays are an inherent property of the given network, much like in real life. As stated before, we give each edge a delay distribution, and the delays of messages traveling along that edge are sampled from this distribution. This allows us to model real-life networks where the adversary cannot tamper with the network connections. For example, on the Internet, delays between two directly connected nodes depend on their distance and the reliability of their connection.

2.2 Adversary

We consider an adversary, who statically and passively corrupts any set $\mathcal {Z}\subseteq \mathcal {P}=\{P _1,\dots ,P _n\}$ of parties, with $|\mathcal {Z}|<n$. Static corruptions mean that the set $\mathcal {Z}$ is chosen before the protocol execution. Passively corrupted parties follow the protocol instructions, but the adversary can access their internal states during the execution.

The setting with passive corruptions and secure hardware boxes is somewhat subtle. In particular, the adversary is allowed to input to the box of a corrupted party any messages of his choice, even based on secret states of other corrupted parties; he can even replay messages from honest parties with different corrupted inputs. This will be why we need authenticated encryption, for example. Importantly, in the passive model, the messages actually sent by a corrupted party are produced using the box with valid inputs.

2.3 Communication Network and Clocks

Clocks. Each party has access to a clock that ticks at the same rate as every other clock. These ticks are fast; one can think of them as being milliseconds long or even faster (essentially, the smallest measurable unit of time).

We model the clocks by the clock functionality $\mathcal {F}_{\textsc {clock}}$ of [KMTZ13], which we recall here for completeness. The functionality keeps the absolute time $\tau$, which is just the number of ticks that have passed since the initialization. Every single tick, a party is activated, given the time, and runs a part of the protocol. To ensure that honest parties are activated at least once every clock tick, the absolute time is increased according to “Ready” messages from honest parties.

Because clocks wait for “Ready” messages, computation is instant, happening within a single clock-tick. While this is not exactly what happens in the real world, our protocols do not abuse this property. In particular, they proceed in rounds, where each round takes a number (e.g., one million) clock-ticks. Parties process and send messages only once in a round, and remain passive at other times (in real world, this would be the time they perform the computation).

Network. The (incomplete) network with delays is modeled by the network functionality $\mathcal {F}_{\textsc {net}}$. Similar to the synchronous models for THC, the description of the communication graph is inputted before the protocol execution by a special party $P_{\mathsf {setting}}$. In our case, this description also contains a (possibly different) probability distribution for each edge indicating its delay. Each party can ask the functionality for its neighborhood in the communication graph and the delay distributions on the edges to its neighbors.³ During the protocol execution, at every clock tick, parties can send to each neighbor a message, which is delivered after a delay sampled from a given distribution.

Leakage in the Ideal World. During the protocol execution the adversary can learn local neighborhoods from $\mathcal {F}_{\textsc {net}}$. Therefore, any ideal-world adversary should also have access to this information. This is ensured by the ideal-world functionality $\mathcal {F}_{\textsc {info}} ^{\mathcal {L}}$, which has the same initialization step and the same graph information as $\mathcal {F}_{\textsc {net}}$, but does not allow for actual communication.

Moreover, in any protocol it is unavoidable that the adversary learns the time at which the output is revealed. In previous synchronous THC protocols, this quantity corresponded to a fixed number of rounds (depending on an upper bound on the graph size or its diameter). This can no longer be the case in our model, where the number of rounds it takes to deliver a message is unbounded. Hence, it is necessary to parameterize $\mathcal {F}_{\textsc {info}} ^{\mathcal {L}}$ by a leakage function $\mathcal {L}$, that allows the adversary to compute the output time. $\mathcal {L}$ depends on the set $\mathcal D$ of all delay distributions in the network, but it does not depend on the communication graph itself. Additionally, we allow the adversary to pass to $\mathcal {L}$ an auxiliary input, that will accommodate any protocol parameters that influence the output time.

For example, in our protocol based on secure hardware, $\mathcal {L}$ will return the distribution of the sum of all network delays, rounded to the next multiple of the round length $R$ (where $R$ is provided as auxiliary input by the adversary).

2.4 Additional Related Work

Katz et al. [KMTZ13] introduce eventual-delivery and channels with a fixed known upper bound. These functionalities implement communication between two parties, where the adversary can set, for each message, the delay after which it is delivered. For reasons stated at the beginning of this section, such functionalities cannot be used directly to model topology-hiding computation. Instead of point-to-point channels we need to model the whole communication network, and we cannot allow the adversary to set the delays. Intuitively, $\mathcal {F}_{\textsc {net}}$ implements a number of bounded-delay channels, each of which is modified so that the delay is chosen once and independently of the adversary. If we did not consider hiding the topology, our modified channels would be a stronger assumption.

Cohen et al. [CCGZ16] define different channels with probabilistic delays, for example point-to-point channels (the SMT functionalities) and an all-to-all channel (parallel SMT, or PSMT). However, their PSMT functionality cannot be easily modified to model THC, since the delivery time is sampled once for all parties. One could modify the SMT functionalities and use their parallel composition, but we find our formulation simpler and much better suited for THC.

3 Protocols for Restricted Classes of Graphs

This section considers protocols that realize topology-hiding broadcast in the Probabilistic Unknown Delay Model under standard assumptions (in particular, we give an instantiation based on DDH), but in the limited setting where graphs are trees or cycles. We stress that we can deal with any graphs if a spanning tree is revealed. In the following, we first recall the known technique to achieve fully-synchronous THC using random walks and so-called PKCR encryption [ALM17]. Then, we extend PKCR by certain additional properties, which allows us to construct a broadcast protocol for cycles in the Probabilistic Unknown Delay Model. Finally, we extend this protocol to trees.

3.1 Synchronous THC from Random Walks

Currently, the most efficient fully-synchronous THC protocols are based on the technique of correlated random walks, introduced in [ALM17]. Intuitively, a $\textsf {PKCR}$ scheme is assumed, which is an enhanced public-key encryption scheme on group elements, where the public keys come with a group operation: we write $\texttt {pk} _{12} = \texttt {pk} _1\circledast \texttt {pk} _2$. The encryption and decryption algorithms are denoted $\textsf {PKCR.Enc} (m,\texttt {pk})$ and $\textsf {PKCR.Dec} (c,\texttt {sk})$, respectively. Additionally, a party can add a layer of encryption to a ciphertext c encrypted under $\texttt {pk} _1$, using the algorithm $\textsf {PKCR.AddLayer} (c,\texttt {sk} _2)$, which outputs an encryption $c'$ under the combined key $\texttt {pk} _{12}$. This operation can be undone with $\textsf {PKCR.DelLayer} (c',\texttt {sk} _2)$. We also require that PKCR is homomorphic and rerandomizable (note that the latter is implied).

The goal is to broadcast one bit. However, we instead realize the OR functionality, which can then be used for broadcast (in the semi-honest setting) by having the sender input his bit, and all other parties input 0. The protocol proceeds as follows. A party starts by encrypting 0 if its input bit is 0, and a random group element otherwise, under a fresh key. In the first, so-called aggregate phase, this ciphertext travels along a random walk for a fixed number of rounds R (collecting the input bits of each party until it has traversed the whole graph with high probability). In each round, each party adds a layer of encryption to the received ciphertext (using a freshly generated key) and homomorphically adds its input. After R rounds, the parties start the decrypt phase, in which they send the final ciphertext back through the same walk it traversed in the first phase, and the layers of encryption are removed (using the secret keys stored during the aggregate phase). It is important that the ciphertext is sent via the same walk, to remove exactly the same layers of encryption that were added in the first phase. The parties determine this walk based on how they routed the ciphertext in the corresponding round of the aggregate phase. After another R rounds, each party interprets the group element as a 0-bit (the 0 element) or as a 1-bit (any other element).

This technique breaks down in the Probabilistic Unknown Delay Model. For example, it is not clear how to choose R such that the walk traverses the whole graph since it would depend on an upper bound on the delays. Moreover, in the decrypt phase, parties no longer know how to route a ciphertext back via the same walk it took in the aggregate phase. This is because they do not know the number of steps it already made in the backward walk (this depends on the actual delays). Furthermore, it is not straightforward to modify the random walk technique to deal with this. For instance, the standard method of attaching a round number to every message (to count the number of encryption layers) reveals information about the topology.

3.2 Protocol for Cycles

We assume an enhanced $\textsf {PKCR}$ scheme, denoted $\textsf {PKCR*}$. The main differences from $\textsf {PKCR}$ are as follows. First, the message space in $\textsf {PKCR*}$ is now the set $\{0,1\}$, and it is disjoint from the ciphertext space. This allows to distinguish between a layered ciphertext and a plaintext. Moreover, we no longer require explicit homomorphism, but instead use the algorithm $\textsf {PKCR*.ToOne} (c)$ that transforms an encryption of 0 into an encryption of 1 without knowing the public key.⁴ We formally define $\textsf {PKCR*}$ and give an instantiation based on the DDH assumption in Appendix B.

Rounds. Although we are striving for a protocol that behaves in a somewhat asynchronous way, we still have a notion of rounds defined by a certain number of clock ticks. Even though each party is activated in every clock tick, each party receives, processes and sends a message only every $R$ clock ticks—this keeps parties in sync despite delays, without clogging the network. Even if no message is received, a message is sent.⁵ This means that at time $\tau$, we are on round $\mathsf {r}_\tau = \lfloor \tau / R\rfloor$; the $\tau$ parameter will be dropped if obvious from context. Moreover, observe that the message complexity increases as $R$ decreases. For reference, $R$ can be thought of as relatively large, say 1,000 or more; this is also so that parties are able to completely process messages every round.

A Protocol with Constant Delays. To better explain our ideas, we first describe our protocol in the setting with constant delays, and then modify it to deal with any delay distributions.

The high-level idea is to execute directly the decrypt phase of the random-walk protocol, where the walk is simply the cycle traversal, and the combined public key corresponding to the ciphertext resulting from the aggregate phase is given as the setup (note that this is independent of the order of parties on the graph). More concretely, we assume that each party $P _i$ holds a secret key $\texttt {sk} _i$ and the combined public key $\texttt {pk} = \texttt {pk} _1\circledast \dots \circledast \texttt {pk} _n$. Assume for the moment that each party knows who the next clockwise party is in the cycle. At the beginning, a party $P_i$, every round (i.e., every $R$ clock ticks), starts a new cycle traversal by sending to the next party a fresh encryption of its input $\textsf {PKCR*.Enc} (b_i,\texttt {pk})$. Once $P_i$ starts receiving ciphertexts from its neighbor (note that since the delays are fixed, there is at most one ciphertext arriving in a given round), it instead continues the cycle traversals. That is, every time it receives a ciphertext c from the previous neighbor, it deletes the layer of encryption using its secret key: $\textsf {PKCR*.DelLayer} (c,\texttt {sk} _i)$. It then rerandomizes the result and sends it to the next party. The sender additionally transforms the ciphertext it receives to a 1-ciphertext in case its bit is 1. After traversing the whole cycle, all layers of encryption are removed and the parties can recognize a plaintext bit. This happens at the same time for every party.

In order to remove the assumption that each party knows who the next clockwise party is, we simply traverse the cycle in both directions.

A Protocol Accounting for Variable Delays. The above approach breaks down with arbitrary delays, where many messages can arrive at the same round. We deal with this by additionally ensuring that every message is received in a predictable timely manner: we will be repeating message sends. As stated in Sect. 2, the delays could be variable, but we make the assumption that if messages are sent at least $R$ clock-ticks from each other, then the delay for each message is independent. We also assume that the median value of the delay along each edge is polynomial, denoted as ${\text {Med}}[D_{e}]$. Now, since the protocol will handle messages in rounds, the actual values we need to consider are all in rounds: $\left\lceil {\text {Med}}[D_{e}]/R\right\rceil$.

Now, if over $\kappa$ rounds, $P _1$ sends a message c each round, the probability that none of the copies arrives after $\kappa + \left\lceil {\text {Med}}[D_{e}]/R\right\rceil$ rounds is negligible in terms of $\kappa$, the security parameter (see full version [LLM+19] for the proof). Because we are guaranteed to have the message by that time (and we believe with reasonable network delays, median delay is small), we wait until time $(\kappa + \left\lceil {\text {Med}}[D_{e}]/R\right\rceil ) \cdot R$ has passed from when the original message was sent before processing it.⁶

For the purposes of this sketch, we will just consider sending messages one way around the protocol. We will also focus on $P _1$ (with neighbors $P _n$ and $P _2$) since all parties will behave in an identical manner. First, the setup phase gives every party the combined public key $\texttt {pk} = \texttt {pk} _1\circledast \dots \circledast \texttt {pk} _n$. At each step, processing a message will involve using the $\textsf {PKCR.DelLayer}$ functionality for their key.

In the first round, $P _1$ sends its bit (0 if not the source node, $b_s$ if the source node) encrypted under $\texttt {pk}$ to $P _2$, let’s call this message $c^{(1)}_1$. $P _1$ will wait $\mathsf {w}= \kappa + \left\lceil {\text {Med}}[D_{e}]/R\right\rceil$ rounds to receive $P _n$’s first message during this time. Now, because $P _1$ needs to make sure $c^{(1)}_1$ makes it to $P _2$, for the next $\kappa$ rounds, $P _1$ continues to send $c^{(1)}_1$. However, because $P _1$ also needs to hide $\mathsf {w}$ (and thus cannot reveal when it starts sending its processed message from $P _n$), $P _1$ starts sending a new ciphertext encrypting the same message, $c^{(1)}_2$ (again $\kappa$ times over $\kappa$ rounds), until it has waited $\mathsf {w}$ rounds—so, $P _1$ is sending $c^{(1)}_1$ and $c^{(1)}_2$ in the second round, $c^{(1)}_1$, $c^{(1)}_2$ and $c^{(1)}_3$ the third round and so forth until it sends $c^{(1)}_1,\dots c^{(1)}_\kappa$ in round $\kappa$. Then it stops sending $c^{(1)}_1$ and starts sending $c^{(1)}_{\kappa +1}$. $P _1$ will only ever send $\kappa$ messages at once per round. Once it has waited $\mathsf {w}$ rounds, $P _1$ is guaranteed to have received the message from $P _n$ and can process and forward that message, again sending it $\kappa$ times over $\kappa$ rounds. In the next round, $P _1$ will then be guaranteed to receive the next message from $P _n$, and so on.

Let $\text {MedRSum[D]}= \sum _{i=1}^n \left\lceil {\text {Med}}[D_{(i,(i+1 \mod n) + 1)}]/R\right\rceil$ denote the median-round-sum of the delays. Because each party waits like this, the protocol has a guaranteed time to end, the same for all parties:

$$ R\cdot \sum _{i=1}^n \mathsf {w}_i = R\left( n\kappa + \text {MedRSum[D]}\right) . $$

This is the only information ‘leaked’ from the protocol: all parties learn the sum of ceiling’d medians, $\text {MedRSum[D]}$. Additionally, parties all know the (real, not a round-delay) distribution of delays for messages to reach them, and thus can compute $\left\lceil {\text {Med}}[D_{e}]/R\right\rceil$ for their adjacent edges.

Formally, the protocol $\textsf {CycleProt}$ is described as follows.

In the full version [LLM+19] we prove the following theorem ($\mathcal {F}_{\textsc {BC}}$ denotes the broadcast functionality).

Theorem 1

The protocol CycleProt UC-realizes $(\mathcal {F}_{\textsc {clock}}, \mathcal {F}_{\textsc {info}} ^{{\mathcal {L}_\mathsf {median}}}, \mathcal {F}_{\textsc {BC}})$ in the $(\mathcal {F}_{\textsc {clock}},\mathcal {F}_{\textsc {net}}$)-hybrid model with an adversary who statically passively corrupts any number of parties, where the leakage function is defined as ${\mathcal {L}_\mathsf {median}}(R,\mathcal D) = \mathrm{MedRSum[D]}$.⁷

3.3 Protocol for Trees

We show how to modify the cycle protocol presented in the previous section to securely realize the broadcast functionality $\mathcal {F}_{\textsc {BC}}$ in any tree. As observed in [AM17], given a tree, nodes can locally compute their local views of a cycle-traversal of the tree. However, to apply the cycle protocol to this cycle-traversal, we would need as setup a combined public key that has each secret key $\texttt {sk} _i$ as many times as $P _i$ appears in the cycle-traversal. To handle that, each party simply removes its secret key from the ciphertexts received from the first neighbor, and we can assume the same setup as in the cycle protocol.

In the full version [LLM+19] we give a formal description of the protocol $\textsf {TreeProt}$. The proof of the following theorem is a straightforward extension of the proof of Theorem 1.

Theorem 2

The protocol TreeProt UC-realizes $(\mathcal {F}_{\textsc {clock}}, \mathcal {F}_{\textsc {info}} ^{{\mathcal {L}_\mathsf {median}}}, \mathcal {F}_{\textsc {BC}})$ in the $(\mathcal {F}_{\textsc {clock}},\mathcal {F}_{\textsc {net}}$)-hybrid model with an adversary who statically passively corrupts any number of parties, where the leakage function is defined as ${\mathcal {L}_\mathsf {median}}(R,\mathcal D) = \mathrm{MedRSum[D]}$.

4 Protocol for General Graphs

We present a protocol that allows us to securely realize any functionality in any connected communication graph with unknown delay distributions on the edges. For that, we use the same setup as [BBMM18]: we assume that the parties have access to secure hardware boxes, initialized with the same secret key, and executing the same functionality $\mathcal {F}_{\textsc {HW}}$, independent of the graph and the realized functionality (see [BBMM18] for details of this model).

Our protocol is divided into two sub-protocols: preprocessing and computation. Both sub-protocols do not terminate on their own. Rather, we assume that each party gets a signal when it can finish each sub-protocol.⁸ The preprocessing is executed only once, before any input is specified and can be re-used. Intuitively, it outputs, for each party, an encryption of the entire communication graph under the secret key embedded in the hardware boxes. The computation allows to evaluate any function, with the help of the encrypted information outputted by the preprocessing. One output of preprocessing can be used to execute the computation any number of times, each time with different function and different inputs.

In the following, we formally describe both protocols. To make the exposition easier to follow, we postpone the precise definition of the functionality $\mathcal {F}_{\textsc {HW}}$ executed by the hardware boxes, to Appendix C, and for now only give an informal description of its behavior whenever $\mathcal {F}_{\textsc {HW}}$ is invoked.

4.1 Preprocessing

The preprocessing is executed without any inputs. The output is a pair $(\texttt {id} _i,c)$, where $\texttt {id} _i$ is a (secret) random string used to identify a party, and c is a ciphertext that contains an encrypted state with the whole graph. This output pair will be inputted to the computation protocol.

At a high level, the protocol floods the network with encrypted partial images of the graph, until the signal to terminate occurs. We assume that the signal occurs late enough for all parties to collect all information. In more detail, throughout the protocol, a party $P_i$ keeps an encrypted state c, containing information about the graph and parties’ $\texttt {id}$’s, that it collected up to a given point. Initially, c contains only the local neighborhood and $\texttt {id} _i$ chosen at random by $P_i$. Then, every round, $P _i$ sends c to all its neighbors. When it receives a state $c_j$ from a neighbor $P _j$, it uses the functionality $\mathcal {F}_{\textsc {HW}}$ box to update c with the information from $c_j$. That is, $\mathcal {F}_{\textsc {HW}}$ gets as input two encrypted states containing partial images on the graph, respectively, decrypts both states and merges the information into a new state, which is encrypted and output.

4.2 Computation

The inputs to the computation protocol are, for every $P _i$, its input $x_i$, a description of the function $f_i$ that evaluates $P _i$’s output of the computed function, and the values $\texttt {id} _i$ and $c_i$, outputted by preprocessing.

The high-level idea is that the hardware box $\mathcal {F}_{\textsc {HW}}$ gets as part of its input the value $c_i$, containing, among others, the encrypted communication graph. This allows it to deterministically compute an Eulerian cycle, which visits every edge exactly twice. Then, every party starts a traversal of the Eulerian cycle, in order to collect the inputs from all parties. Once all inputs are collected, the box computes the function and gives the output to the party. Traversing each edge exactly twice allows all parties to learn the output at a time that does not depend on the graph topology but (roughly) on the distribution of the sum of the delays. Of course, all messages are encrypted under the secret key embedded in the hardware boxes.

This means that at any time during the protocol there are n cycle traversals going through the graph (one per a starting party). Each of the traversals visits all edges in the graph twice. So in each round a party $P_i$ processes messages for up to n traversals. To hide the number of actual traversal processed $P_i$ sends n messages to each of its neighbors. This means that each round, $P _i$ receives from each neighbor n messages. It inputs all of them to its hardware box (together with its input to the computed function) and receives back, for each neighbor, a set of n messages that it then sends to him.

A party receives the output once the cycle has been traversed, which takes time proportional to the sum of the rounded delays. Once the parties receive output, they continue executing the protocol until they receive the termination signal, which we assume occurs late enough for all parties to get their outputs.

There are still some subtle issues, that the above sketch does not address. First, the adversary could try to tamper with the ciphertexts. For example, in our protocol a message contains a list of $\texttt {id}$’s that identifies the path it already traversed. This is done so that the adversary cannot extend the traversal on behalf of an honest party $P_i$ without knowing its secret $\texttt {id} _i$. Now the adversary could try to extend this list nevertheless, by copying part of the encrypted state of a corrupted party—recall that this state contains all $\texttt {id} _i$’s. To prevent such situations, we use authenticated encryption.

Second, we need to specify when the parties input the function they are evaluating into the box. Doing this at the very end would allow the adversary to evaluate many functions of her choice, including the identity. So instead, in our protocol the function is inputted once, when the cycle traversal is started, and it is always a part of the message. This way, when the output is computed, the function is taken from a message that has been already processed by all honest parties. Since honest parties only process messages that are actually sent to them, and even corrupted parties only send correctly generated messages, this function must be the correct one. In some sense, when sending the first message to an honest party, the adversary commits herself to the correct function.

A similar problem occurs when the parties input to their boxes the inputs to the computed function. A sequence of corrupted parties at the end of the traversal can emulate the last steps of the protocol many times, with different inputs. To prevent this, we traverse the cycle twice. After the first traversal, the inputs are collected and the function is evaluated. Then, the (still encrypted) output traverses the cycle for the second time, and only then is given to the parties.

Finally, we observe that at the end of the protocol, a graph component of neighboring corrupted parties learns where the traversal enters their component (this can be done by fast-forwarding the protocol). Depending on how the eulerian cycle is computed, this could leak information about the topology. To address this, we introduce in Sect. 4.3 an algorithm for computing the traversal that does not have this issue (formally, the last part of the cycle can be simulated).

Realizing Reactive Functionalities. Reactive functionalities are those which require explicit interaction between parties, e.g. if the function we realize is very simple but we want to evaluate a complex function, parties may need to run this protocol multiple times in sequence, using previous outputs to generate the next inputs. Our current hardware protocol allows us to realize secure function evaluation. In the synchronous setting, this can be easily extended to reactive functionalities by invoking many function evaluations in sequence. However, in the setting with unknown delays this is no longer clear. For example, if our protocol is composed sequentially in the naive way, then parties start the second execution at different times, which leaks topology.

So, to get reactive functionalities or composition to work for this hardware protocol we can do one of two things. First, we could add a synchronization point before each ‘round’ of the reactive function. Second, we could employ the same trick as for the cycle/tree protocol in Sect. 3, sending the same message many times so that with high probability it arrives to the next node within some reasonable time interval. With this method, every party ends the protocol at exactly the same time, and so can start the next protocol at the same time, despite the delays.

The running time of the protocol $\textsf {Hardware}$ depends only on the sum of all delays in the network, each rounded to the next multiple of the round length $R$, which is the only information leaked in the ideal world. In the full version [LLM+19] we prove the following theorem.

Theorem 3

For any efficiently computable and well-formed⁹ functionality $\mathcal {F}$, the protocol Hardware UC-realizes $(\mathcal {F}_{\textsc {clock}}, \mathcal {F}_{\textsc {info}} ^{{\mathcal {L}_\mathsf {sum}}}, \mathcal {F})$ in the $(\mathcal {F}_{\textsc {clock}},\mathcal {F}_{\textsc {net}},\mathcal {F}_{\textsc {HW}}$)-hybrid model with an adversary who statically passively corrupts any number of parties, where .

Remark

One can observe that in our protocol the hardware boxes must be able to evaluate a complex function. This can be resolved at the cost of efficiency, by computing the functionality by many calls to the simple broadcast functionality. Note that even if we require one synchronization point per broadcast, this still seems reasonable, since it is possible to evaluate any function with constant number of broadcasts [DI05, LPSY15].

4.3 Computing the Eulerian Cycle

It turns out that not every algorithm computing an Eulerian cycle can be used in $\mathcal {F}_{\textsc {HW}}$ to achieve THC. In particular, during the execution of our protocol the adversary learns some information about a part of the cycle, which for some algorithms depends on the graph. More technically, during the simulation, it is necessary to compute the time when the adversary learns the output, and this happens as soon as the Eulerian cycle traversal enters a fragment of consecutive corrupted parties containing the output party. This is because it can “fast-forward” the protocol (without communication). Hence, we need an algorithm for computing such a cycle on a graph with doubled edges, for which the “entry point” to a connected component (of corrupted parties) can be simulated with only the knowledge of the component.

Common algorithms, such as Fleury or Hierholzer [Fle83, Fle91], check a global property of the graph and hence cannot be used without the knowledge of the entire graph topology. Moreover, a distributed algorithm in the local model (where the parties only have knowledge of its neighbors) such as [Mak97] is also not enough, since the algorithm has to be executed until the end in order to know what is the last part of the cycle.

We present the algorithm EulerianCycle, which, if executed from a node u on a connected neighborhood containing u, leads to the same starting path as if it was executed on the whole graph. This property is enough to simulate, since the simulator can compute the last fragment of the Eulerian Cycle in the corrupted neighborhood. We note that the start of the cycle generated by our algorithm can be simulated, however, the simulator needs to compute the end. Hence, the hardware boxes will traverse the path outputted by EulerianCycle from the end.

Fig. 1.

An example of a graph G (on the left) and the corresponding tree $\mathcal {T}$, computed by $\mathsf {EulerianCycle}(1,G)$ (on the right). The eulerian cycle (on the graph with doubled edges) is (1, 2, 4, 1, 3, 1, 3, 5, 3, 4, 2, 1).

The idea is to generate a tree from the graph, in such a way that the generated tree contains exactly the same edges as the graph. To do that, the tree is generated in a DFS-manner from a source u. At every step, a new edge (the one that leads to the smallest id according to a DFS order, and without repeating nodes) is added to the tree. Since the graph is connected, all edges are eventually added. Moreover, each edge is added exactly once, since no repeated nodes are expanded. See Fig. 1 for an example execution.

Appendices

Appendix

A Adversarially-Controlled Delays Leak Topology

Much like how adversarially-controlled aborts were shown to leak topological information in [MOR15], we can show that adversarially-controlled delays also leak topological information. First, note that if we have bounded delays, we can always use a synchronous protocol, starting the next round after waiting the maximum delay. So, in order for this model to be interesting, we must assume the adversary has unbounded delays. In order to be as general as possible, we prove this with the weakest model we can while still giving the adversary some control over its delays: the adversary can only add delay to messages leaving corrupt nodes.

Our proof will follow the structure of [MOR15], using a similar game-based definition and even using the same adversarially-chosen graphs (see Fig. 2). Our game is straightforward. The adversary gives the challenger two graphs and a set of corrupt nodes so that the corrupt neighborhoods are identical when there is no adversarially added delay. The challenger then chooses one of those graphs at random, runs the protocol, and gives the views of all corrupt nodes to the adversary. The adversary wins if she can tell which graph was used. In [MOR15], the adversary would choose a round to failstop one of its corrupt parties. In our model, the adversary will instead choose a time (clock-tick) to add what we call a long-delay (which is just a very long delay on sending that and all subsequent messages). The adversary will be able to detect the delay based on when the protocol ends: if the delay was early in the protocol, the protocol takes longer to finish for all parties, and if it was late, the protocol will still finish quickly for most parties.

This impossibility result translates to an impossibility in the simulation-based setting since a secure protocol for the simulation-based setting would imply a secure protocol for the game-based setting.

Fig. 2.

Graphs used to prove the impossibility of THC with adversarial delays. $P_S$ is the sender. The corrupted parties (black dots) are: $P_L$ and $P_R$ (they delay messages), and the detective $P_D$. The adversary determines whether $P_D$ (and its two neighbors) are on the left or on the right.

1.1 A.1 Adversarially-Controlled Delay Indistinguishability-based Security Definition

Before proving the impossibility result, we first formally define our model. This model is as weak as possible while still assuming delays are somewhat controlled by the adversary. We will assume a minimum delay along edges: it takes at least one clock-tick for a message to get from one party to another.

Delay Algorithms. In order to give the adversary as little power as possible, we define a public (and arbitrary) randomized algorithm that outputs the delays for a graph for protocol $\varPi$. Both the adversary and challenger have access to this algorithm and can sample from it.

Definition 1

A indistinguishability-delay algorithm (IDA) for a protocol $\varPi$, ${ \textsf {DelayAlgorithm}}_{\varPi }$, is a probabilistic polynomial-time algorithm that takes as input an arbitrary graph outputs unbounded polynomial delays for every time $\tau$ and every edge in the graph. Explicitely, for any graph $G = (V, E)$, ${ \textsf {DelayAlgorithm}}(G)$ outputs $\mathcal {T}$ such that for every edge $(i,j) \in E_b$ and time $\tau$, $\mathcal {T}((i,j), \tau ) = d_{(i,j), \tau }$ is a delay that is at least one.

The Indistinguishability Game. This indistinguishability definition is a game between an adversary $\mathcal {A}$ and challenger $\mathcal {C}$ adapted from [MOR15]. Let DelayAlgorithm be an IDA as defined above.

• Setup: Let $\mathcal {G}$ be a class of graphs and $\varPi$ a topology-hiding broadcast protocol that works on any of the networks described by $\mathcal {G}$ according to our adversarial delay model, and let ${ \textsf {DelayAlgorithm}}$ be a public, fixed IDA algorithm. Without loss of generality, let $P _1$ have input $x \in \{0,1\}$, the broadcast bit.

• $\mathcal {A}$ chooses two graphs $G_0 = (V_0, E_0)$ and $G_1 = (V_1, E_1)$ from $\mathcal {G}$ and then a subset $\mathcal {Z}$ of the parties to corrupt. $\mathcal {Z}$ must look locally the same in both $G_0$ and $G_1$. Formally, $\mathcal {Z}\subset V_0 \cap V_1$ and $\mathbf {N}_{G_{0}}(\mathcal {Z}) = \mathbf {N}_{G_{1}}(\mathcal {Z})$. If this doesn’t hold, $\mathcal {C}$ wins automatically.

  $\mathcal {A}$ then generates $\mathcal {T}_{\mathcal {Z}}$, a function defining delays for every edge at every time-step controlled by the adversary. That is, $\mathcal {T}_{\mathcal {Z}}((i,j), \tau ) = d_{(i,j),\tau }$, and if $P _i \in \mathcal {Z}$, then every message sent from $P _i$ to $P _j$ at time $\tau$ is delayed by an extra $d_{(i,j), \tau }$.

  $\mathcal {A}$ sends $G_0, G_1, \mathcal {Z},$ and $\mathcal {T}_{\mathcal {Z}}$ to $\mathcal {C}$.

• $\mathcal {C}$ chooses a random $b \in \{0,1\}$ and executes $\varPi$ in $G_b$ with delays according to ${ \textsf {DelayAlgorithm}}(G_b) = \mathcal {T}$ for all messages sent from honest parties. For messages sent from corrupt parties, delay is determined by the time and parties as follows: for time $\tau$ a message sent from party $P _i \in \mathcal {Z}$ to $P _j$ has delay $\mathcal {T}((i,j), \tau ) + \mathcal {T}_{\mathcal {Z}}((i,j), \tau )$ in reaching $P _j$. $\mathcal {A}$ receives the view of all parties in $\mathcal {Z}$ during the execution.

• $\mathcal {A}$ then outputs $b' \in \{0,1\}$ and wins if $b' = b$ and loses otherwise.

Notice that in this model, the adversary statically and passively corrupts any set of parties, and statically determines what delays to add to the protocol.

Definition 2

A protocol $\varPi$ is indistinguishable under chosen delay attack (IND-CDA) over a class of graphs $\mathcal {G}$ if for any PPT adversary $\mathcal {A}$, there exists an IDA ${ \textsf {DelayAlgorithm}}$ such that

$$\begin{aligned} \Pr [\mathcal {A} \text{ wins }] \le \frac{1}{2} + \text {negl}(n). \end{aligned}$$

1.2 A.2 Proof that Adversarially-Controlled Delays Leak Topology

First, we will define what we mean when we say a protocol is ‘weakly’ realized in the adversarial delay model. Intuitively, it is just that the protocol outputs the correct bit to all parties if there is no adversarial delay.

Definition 3

A protocol $\varPi$ weakly realizes the broadcast functionality if $\varPi$ is such that when all parties execute honestly with delays determined by any IDA, all parties get the broadcast bit within polynomial time (with all but negligible probability).

Theorem 4

There does not exist an IND-CDA secure protocol $\varPi$ that weakly realizes the broadcast functionality of any class of graphs $\mathcal {G}$ that contains line graphs.

Throughout the proof and associated claim, we refer to a specific pair of graphs that the adversary has chosen to distinguish between, winning the IND-CDA game. Both graphs will be a line of n vertices: $G = (V,E)$ where $E = \{(P _i, P _{i+1})\}_{i=1,\ldots ,n-1}$. We will let $\varPi$ be a protocol executed on G that weakly realizes broadcast when $P_1$ is the broadcaster, see Fig. 2.

Our adversary in this model will either add no delay, or will add a very long polynomial delay to every message sent after some time $\tau$.

Notice that $\mathcal {A}$ is given access to ${ \textsf {DelayAlgorithm}}$ at the start of the protocol. One can sample from ${ \textsf {DelayAlgorithm}}$ using $G_0$, $G_1$, and $\mathcal {Z}$ to get an upper bound T on the time it takes $\varPi$ to terminate with all but negligible probability. Since $\varPi$ weakly realizes broadcast, T is polynomial. So, $\mathcal {A}$ has access to this upper bound T.

Long-Delays. Let a long-delay be a delay that lasts for T clock-ticks. Consider an adversary that will only add long-delays to a protocol, and once an adversary has long-delayed a message, he must continue to long-delay messages along that edge until the end of the protocol. That is, once the adverary decides to delay along some edge, all subsequent messages along that edge cannot arrive for at least T clock-ticks.

Claim

Consider any party $P _v$ whose neighbors do not add any extra delay as described by the long-delay paragraph above. As in [MOR15], let $H_{v,b}$ be the event that $P _v$ outputs the broadcast bit by time T ($P _v$ may still be running the protocol by time T or terminate by guessing a bit by T). Let $E_\tau$ be the event that the first long-delay is at time $\tau$. Then either $\varPi$ is not IND-CDA secure, or there exists a bit b such that

$$\begin{aligned} |\Pr \left[ H_{v,b} | E_{T-1} \right] - \Pr \left[ H_{v,b} | E_{0} \right] |\ge \frac{1}{2} - \text {negl}(n). \end{aligned}$$

Proof

If some $P _i$ long-delays at time 0, then the first message it sends is at time T, and so the graph is disconnected until time T. This makes it impossible for parties separated from $P _1$ to learn about the output bit by time T. So, by that time, these parties must either guess an output bit (and be right with probability at most 1/2) or output nothing and keep running the protocol (which is still not $H_{v,b}$). If $\varPi$ is IND-CDA secure, then all honest parties must have the same probability of outputting the output bit by time T, and so there exists a b such that $\Pr [H_{v,b} | E_0] \le \frac{1}{2} - \text {negl}(n)$ for all honest parties $P _v$.

However, if $P _i$ long-delays at time $T-1$, then the only parties possibly affected by $P _i$ are $P _{i-1}$ and $P _{i+1}$; all other parties will get the output by time T and the information that $P _i$ delayed cannot reach them (recall we assumed a minimum delay of at least one clock-tick in the ${ \textsf {DelayAlgorithm}}$). So, $\Pr [H_{v,b} | E_0] = \Pr [H_{v,b} | \text{ no } \text{ extra } \text{ delays }] = 1 - \text {negl}(n)$ for all honest parties without a delaying neighbor by the definition of weakly realizing broadcast.

The claim follows: $|\Pr \left[ H_{v,b} | E_{T-1} \right] - \Pr \left[ H_{v,b} | E_{0} \right] |\ge |\frac{1}{2} - \text {negl}(n) - 1 |\ge \frac{1}{2} - \text {negl}(n)$.    $\square$

Proof

(Theorem 4). This just follows from the previous claim. A simple hybrid argument shows that there exists a pair $(\tau ^*, b) \in \{0,\ldots , T-1\} \times \{0,1\}$ such that

$$\begin{aligned} |\Pr \left[ H_{v,b} | E_{\tau ^*} \right] - \Pr \left[ H_{v,b} | E_{\tau ^* + 1} \right] |\ge \frac{1}{2T} - \text {negl}(n) \end{aligned}$$

for all $P_v$ who do not have a neighbor delaying. Since T is polynomial, this is a non-negligible value. Without loss of generality, assume $\Pr [ H_{v,b} | E_{\tau ^*}] > \Pr [H_{v,b} | E_{\tau ^* + 1}]$. Leveraging this difference, we will construct an adversary $\mathcal {A}$ that can win the IND-CDA game with non-negligible probability.

$\mathcal {A}$ chooses two graphs $G_0$ and $G_1$. $G = G_0$ and $G_1$ is G except parties 3, 4, and 5 are exchanged with parties $n-2$, $n-1$, and n respectively. $\mathcal {A}$ corrupts the source part $P _S := P _1$, a left party $P _L := P _{n/2-1}$, a right party $P _R := P _{n/2 + 1}$, and the detective party $P _D := P _4$. See Fig. 2 for how this looks. The goal of $\mathcal {A}$ will be to determine if $P _D$ is to the left or right side of the network (close to the broadcaster or far).

$\mathcal {A}$ computes the upper bound T using ${ \textsf {DelayAlgorithm}}$ and randomly guesses $(\tau ^*, b)$ that satisfy the inequality above. At time $\tau$, $\mathcal {A}$ initiates a long-delay at party $P _L$, and at time $\tau +1$, $\mathcal {A}$ initiates a long-delay at party $P _R$. So, $\mathcal {A}$ gives the challenger $\mathcal {T}_{\mathcal {Z}}$ where $\mathcal {T}_{\mathcal {Z}}((i,j), t) = 0$ for $t < \tau ^*$, and for $t \ge \tau ^*$: $\mathcal {T}_{\mathcal {Z}}((L, n/2), t) = \mathcal {T}_{\mathcal {Z}}((L, n/2-2), t) T$ and $\mathcal {T}_{\mathcal {Z}}((R, n/2), t+1) = \mathcal {T}_{\mathcal {Z}}((R, n/2 + 2), t+1) = T$.

Notice that news of $P_L$’s delay at time $\tau ^*$ cannot reach $P_R$ or any other party on the right side of the graph by time T. Also note that the time $\mathcal {A}$ gets output for each of its corrupt parties is noted in the transcript.

If $\mathcal {C}$ chooses $G_0$, then $P _D$ is on the left side of the graph and has probability $\Pr [H_{D, b} | E_{\tau ^*}]$ of having the output bit by time T because its view is consistent with $P _L$ delaying at time $\tau ^*$. If $\mathcal {C}$ chooses $G_1$, then $P _D$ is on the right side of the graph, and has a view consistent with the first long delay happening at time $\tau ^*+1$ and therefore has $\Pr [H_{D,b} | E_{\tau ^*}]$ of having the output bit by time T. Because there is a noticeable difference in these probabilities, $\mathcal {A}$ can distinguish between these two cases with $\frac{1}{2}$ plus some non-negligible probability.    $\square$

Consequences of this Lower Bound. We note that this is just one model where we prove it is impossible for the adversary to control delays. However, we restrict the adversary a great deal, to the point of saying that regardless of what the natural network delays are, the adversary can learn something about the topology of the graph. The lower bound proved in this model seems to rule out any possible model (simulation or game-based) where the adversary has power over delays.

B $\textsf {PKCR*}$ Encryption

This section formally defines $\textsf {PKCR*}$—the extended Privately Key Commutative and Rerandomizable (PKCR) encryption of [AM17].

Let $\mathcal {PK}$, $\mathcal {SK}$ and $\mathcal {C}$ denote the public key, secret key and ciphertext spaces. In contrast to PKCR, the message space is $\{0,1\}$. Moreover, $\mathcal {C}\cap \{0,1\}=\varnothing$. As in any public-key encryption scheme, we have the algorithms $\textsf {PKCR*.KGen}:\{0,1\}^* \rightarrow \mathcal {PK}\times \mathcal {SK}$ and $\textsf {PKCR*.Enc}:\{0,1\} \times \mathcal {PK}\rightarrow \mathcal {C}$ for key generation and encryption, respectively (decryption can be implemented via deleting layers). Moreover, we require the following properties, where only the first two are provided (with minor differences) by PKCR.

• Key-Commutative. $\mathcal {PK}$ forms a commutative group under the operation $\circledast$. In particular, given any $\texttt {pk} _1, \texttt {pk} _2 \in \mathcal {PK}$ and the secret key $\texttt {sk} _1$ corresponding to $\texttt {pk} _1$, we can efficiently compute $\texttt {pk} _3 = \texttt {pk} _1 \circledast \texttt {pk} _2 \in \mathcal {PK}$ (note that $\texttt {sk} _1$ can be replaced by $\texttt {sk} _2$, since $\mathcal {PK}$ is commutative).

  This group must interact well with ciphertexts; there exists a pair of deterministic efficiently computable algorithms $\textsf {PKCR*.AddLayer}: \mathcal {C}\times \mathcal {SK}\rightarrow \mathcal {C}$ and $\textsf {PKCR*.DelLayer}: \mathcal {C}\times \mathcal {SK}\rightarrow \mathcal {C}\cup \{0,1\}$ such that for every pair of public keys $\texttt {pk} _1, \texttt {pk} _2 \in \mathcal {PK}$ with corresponding secret keys $\texttt {sk} _1$ and $\texttt {sk} _2$, for every bit $b \in \{0,1\}$, and every ciphertext $c = \textsf {PKCR*.Enc} (b,\texttt {pk} _1)$, with overwhelming probability it holds that:

  • The ciphertext $\textsf {PKCR*.AddLayer} (c, \texttt {sk} _2)$ is an encryption of b under the public key $\texttt {pk} _1 \circledast \texttt {pk} _2$.

  • $\textsf {PKCR*.DelLayer} (c, \texttt {sk} _2)$ is an encryption of b under the public key $\texttt {pk} _1 \circledast \texttt {pk} _2^{-1}$.

  • $\textsf {PKCR*.DelLayer} (c,\texttt {sk} _1)=b$.

  Notice that we need the secret key to perform these operations.¹⁰

• Rerandomizable. There exists an efficient probabilistic algorithm $\textsf {PKCR*.Rand}: \mathcal {C}\rightarrow \mathcal {C}$, which re-randomizes a ciphertext.¹¹ Formally, we require that for every public key $\texttt {pk} \in \mathcal {PK}$, every bit b, and every $c=\textsf {PKCR*.Enc} (b,\texttt {pk})$, the following distributions are computationally indistinguishable:

  $$\begin{aligned} \left\{ (b,c,\texttt {pk},\textsf {PKCR*.Enc} (b, \texttt {pk})) \right\} \approx \left\{ (b,c,\texttt {pk},\textsf {PKCR*.Rand} (c, \texttt {pk})) \right\} \end{aligned}$$

• Transforming a 0-ciphertext to a 1-ciphertext. There exists an efficient algorithm $\textsf {PKCR*.ToOne}: \mathcal {C}\rightarrow \mathcal {C}$, such that for every $\texttt {pk} \in \mathcal {PK}$ and for every $c = \textsf {PKCR*.Enc} (0,\texttt {pk})$, the output of $\textsf {PKCR*.ToOne} (c)$ is an encryption of 1 under $\texttt {pk}$.

• Key anonymity. A ciphertext reveals no information about which public key was used in encryption. Formally, we require that $\textsf {PKCR*}$ is key-indistinguishable (or IK-CPA secure), as defined by Bellare et al. [BBDP01].

1.1 B.1 Construction of $\textsf {PKCR*}$ Based on DDH

We use a cyclic group $G = \langle g \rangle$. We keep as ciphertext a pair of group elements $(c_1,c_2)$. The first group element contains the message. The second group element contains the secret keys of each layer of encryption. All information is contained in the exponent.

To add a layer of encryption with a secret key $\texttt {sk}$, one simply raises the second element to $\texttt {sk}$. Similarly, one can remove layers of encryption. When all layers of encryption are removed, both group elements are either equal $c_1=c_2$ (the message is 0) or $c_1 = c_2^2$ (the message is 1). To transform an encryption of 0 to an encryption of 1, one simply squares the first group element.

The proof of security of our scheme can be found in the full version [LLM+19].

C The Function Executed by the Hardware Boxes

The functionality $\mathcal {F}_{\textsc {HW}}$ contains hard-wired the following values: a symmetric encryption key pk, and a key rk for a pseudo-random function $\textsf {prf}$. Whenever it outputs an encryption, it uses an authenticated encryption scheme $\textsf {AE}$ with key pk, and with encryption randomness computed as $\textsf {prf} _{rk}(x)$, where x is the whole input of $\mathcal {F}_{\textsc {HW}}$. $\mathcal {F}_{\textsc {HW}}$ can receive three types of input, depending on the current stage of the protocol: the initial input and an intermediate input during $\textsf {Hw-Preprocessing}$, and an intermediate input during $\textsf {Hw-Computation}$. On any other inputs, $\mathcal {F}_{\textsc {HW}}$ outputs $\bot$.

Behavior During Preprocessing. During the preprocessing, the first input is a triple $(i,\texttt {id} _i,\mathbf {N}_G(P _i))$, and next inputs are triples $(\texttt {id},c,c_j)$, where c and $c_j$ are states of parties, encrypted under pk. In particular, the state of a party $P_i$ consists of the following information:

• i: the index of $P _i$,

• G: the current image of the graph (stored in an n-by-n matrix),

• $\texttt {ID} =(\texttt {id} _1,\dots ,\texttt {id} _n)$: a vector, containing the currently known identifiers of parties.

On the first input, $\mathcal {F}_{\textsc {HW}}$ outputs an encryption of the initial state, that is, the state where the graph G contains only the direct neighborhood of $P_i$, and $\texttt {ID}$ contains only the value $\texttt {id} _i$ chosen by $P _i$. For the inputs of the form $(\texttt {id},c,c_j)$, $\mathcal {F}_{\textsc {HW}}$ decrypts the states c and $c_j$ and merges the information they contain into a new state s, which it then encrypts and outputs.

Behavior During Computation. Recall that the goal of $\mathcal {F}_{\textsc {HW}}$ at this stage is to compute the next encrypted messages, which a party $P _i$ will send to its neighbors. That is, it takes as input a set of encrypted messages received by $P _i$ and, for each neighbor of $P _i$, outputs a set of n messages to be sent.

Each encrypted message contains information about which graph traversal it is a part of, about the current progress of the traversal, and about all the inputs collected so far. Moreover, we include the information from the encrypted state: $(i,G,\texttt {ID})$ and the function f of the party starting the cycle. Intuitively, the reason for including f and the encrypted state is that, since the adversary is passive, the information taken from the message must be correct (for example, now a corrupted party cannot use its box to evaluate any function of its choice). Formally, an encrypted message from another node decrypts to a message $m_j$ containing the following elements:

• j is the party number (the publicly known number between 1 and n, not the party’s $\texttt {id}$)

• $\texttt {ID} _j$ is the vector of unique random id’s. Carrying this in the message allows us to ensure that inputs are all consistent with the same parties.

• $G_j$ is the adjacency matrix of the network graph. It is also used to check consistency.

• $\texttt {Path} _j=(\texttt {id} ^1,\dots ,\texttt {id} ^{4n^2})$: a vector of length $4n^2$, containing the current set of identifiers of parties visited so far along the graph traversal starting at $P _j$ (recall that the eulerian cycle of length at most $2n^2$ is traversed twice).

• $f_j$ is the function that parties will compute.

• $\vec {x}_j$ is a vector that has a slot for every party to put its input. It starts as being completely empty, but gains an entry when it visits a new node on the graph. We also check this for consistency (a party trying to input a different value from the one they started with will not be able to use the hardware).

At a high level, $\mathcal {F}_{\textsc {HW}}$ first discards any dummy or repeated messages (a party can receive many messages, but the hardware box needs to continue at most n Eulerian cycles), and then processes each remaining message. If a message has traversed the whole Eulerian cycle, $\mathcal {F}_{\textsc {HW}}$ computes and reveals the function applied to the inputs. Otherwise, it creates an encryption of a new message with the current party’s id added to the current path, and its input added to the list of inputs, and $\texttt {next}$ contains the id of the destination neighbor. After processing all messages, for each destination neighbor, it adds correctly formated dummy encryptions, so that exactly n encryptions are sent to each neighbor.

The functionality $\mathcal {F}_{\textsc {HW}}$ is formally described below. It calls the following subroutines:

• AggregateTours takes as input a set of messages M. Each of these messages contain information about a Eulerian Cycle, the party that started that Eulerian Cycle, and the path traversed so far. The subroutine selects the (at most n) messages that start from different parties. It is expected that Eulerian Cycles starting from the same party, are exactly the same message.

• ContinueTour takes as input a specific message, a Eulerian Cycle that the message must traverse, and a current party’s input and number. If the Eulerian Cycle has not been traversed, it then creates a new message containing a path with the current party’s input and id appended to the corresponding variables, and also the id of the party where the message should be sent. Otherwise, it outputs a flag indicating that the Eulerian Cycle has ended and the output must be revealed.

• EncryptAndFormatOutput takes as input a set of pairs message-destination, and appends to each possible destination parsable messages until there are n messages. It then encrypts each message and outputs, for each possible destination a set of encryptions and the id of the party where the encryptions must be sent.