A Privacy Preserving Collusion Secure DCOP Algorithm

05/22/2019 ∙ by Tamir Tassa, et al. ∙ The Open University of Israel Ariel University 0

In recent years, several studies proposed privacy-preserving algorithms for solving Distributed Constraint Optimization Problems (DCOPs). All of those studies assumed that agents do not collude. In this study we propose the first privacy-preserving DCOP algorithm that is immune to coalitions, under the assumption of honest majority. Our algorithm -- PC-SyncBB -- is based on the classical Branch and Bound DCOP algorithm. It offers constraint, topology and decision privacy. We evaluate its performance on different benchmarks, problem sizes, and constraint densities. We show that achieving security against coalitions is feasible. As all existing privacy-preserving DCOP algorithms base their security on assuming solitary conduct of the agents, we view this study as an essential first step towards lifting this potentially harmful assumption in all those algorithms.



There are no comments yet.


page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

Constraint optimization [Meseguer and Larrosa1995] is a powerful framework for describing optimization problems in terms of constraints. In many practical domains, such as Meeting Scheduling [Maheswaran et al.2004], Mobile Sensor nets [Farinelli et al.2008], and the Internet of Things [Lezama et al.2017], the constraints are enforced by distinct participants (agents). Hirayama and Yokoo hirayama97distributed termed such problems as Distributed Constraint Optimization Problems (DCOPs). Various algorithms for solving DCOPs have been proposed, some of which are complete [Gershman et al.2009, Hirayama and Yokoo1997, Mailler and Lesser2004, Modi et al.2005, Petcu and Faltings2005, Yeoh et al.2010], and some are incomplete [Farinelli et al.2008, Katagishi and Pearce2007, Ottens et al.2017, Zhang et al.2005].

The main motivation for DCOP research stems from the inherent distributed structure of many real-world problems, and the privacy concerns that are associated with this distribution. Léauté and Faltings LeaFal13 offered the basic definitions of privacy in this framework. The four notions of privacy that they describe are: agent privacy, topology privacy, constraint privacy and decision privacy (see Section 2). Several studies considered a solution of DCOPs in a manner that preserves (some of) those privacy types.

This line of research began with the work of Silaghi and Mitra Silaghi04. They proposed a privacy-preserving solution to Distributed Weighted Constraint Satisfaction Problems (DisWCSPs); those are distributed problems that are similar to DCOPs, but differ from them in the distribution model and, consequently, in the related privacy targets. Their solution is strictly limited to small scale problems since it depends on an exhaustive search over all possible assignments. As their solution is based on the BGW protocol [Ben-Or et al.1988], it is immune against coalitions that involve less than half of the agents.

All of the subsequent studies considered DCOPs. The main motif in those studies was to develop privacy-preserving versions of existing algorithms. Greenstadt et al. GreGroSmi07 devised a version of the DPOP algorithm [Petcu and Faltings2005], called SSDPOP. Léauté and Faltings LeaFal13 proposed three privacy-preserving versions of DPOP that differ in their privacy guarantees and in their runtime performance. Grinshpoun and Tassa GT16 developed P-SyncBB, a privacy-preserving version of the complete search algorithm SyncBB [Hirayama and Yokoo1997]. Tassa et al. TassaGZ17 presented P-Max-Sum, a privacy-preserving version of the incomplete inference-based Max-Sum algorithm [Farinelli et al.2008]. Lastly, Grinshpoun et al. grinshpoun2019privacy devised P-RODA, a secure implementation of region-optimal algorithms.

All of the above described works based their security on assuming solitary conduct of the agents. Alas, subsets of agents may try to collude and combine the information which they have in order to infer information on other agents. In this paper we suggest the first privacy-preserving DCOP algorithm that is immune against such coalitions. We depart from the SyncBB algorithm and devise a privacy-preserving algorithm that simulates its operation and provides topology, constraint and decision privacies, even in the presence of a coalition of agents, under the assumption of an honest majority (i.e., the size of the coalition is smaller than half the number of agents).

2 Definitions and assumptions

A Distributed Constraint Optimization Problem (DCOP) is a tuple where is a set of agents , is a set of variables , is a set of finite domains , and is a set of relations (constraints). Each variable takes values in the domain , and it is held by a single agent. Each constraint defines a non-negative cost for every possible value combination of a set of variables, and is of the form , for some , and a publicly known maximal constraint cost .

An assignment is a pair including a variable, and a value from that variable’s domain. We denote by the value assigned to the variable . A partial assignment (PA) is a set of assignments in which each variable appears at most once. A constraint is applicable to a PA if all variables that are constrained by are included in the PA. The cost of a PA is the sum of all applicable constraints to the PA. A full assignment is a partial assignment that includes all of the variables. The goal in Constraint Optimization Problems is to find a full assignment of minimal cost.

For simplicity, we assume that each agent holds exactly one variable, i.e., . We let denote hereinafter the number of agents and the number of variables. We consider a binary version of DCOPs, in which every constraints exactly two variables and takes the form . These assumptions are customary in DCOP literature [Modi et al.2005, Petcu and Faltings2005].

Léauté and Faltings LeaFal13 have distinguished between four notions of privacy. The notions of privacy which our proposed algorithm respects are: (a) Topology privacy – hiding from each agent the topological structures in the constraint graph beyond his111We use the masculine form for simplicity. own direct neighborhood in the graph; (b) Constraint privacy – hiding from each agent the constraints in which he is not involved; and (c) Decision privacy – hiding from each agent the final assignments to other variables.

Like in all prior art on privacy-preserving DCOP algorithms, we too assume that the agents are semi-honest, namely, they follow the prescribed protocol but try to glean more information than allowed from the protocol transcript. In contrast to prior art, we assume that (less than half of the) agents may collude in order to combine their inputs and messages received during the execution of the protocol, for the purpose of extracting private information on other agents.

3 A Secure Synchronous Branch and Bound

Synchronous Branch-and-Bound (SyncBB) [Hirayama and Yokoo1997] was the first complete algorithm for solving DCOPs. SyncBB operates in a completely sequential manner, a fact that inherently renders its synchronous behavior. It assumes a static public ordering of the agents, . The search space of the problem is traversed by each agent assigning a value to his variable and passing the current partial assignment (CPA) to the next agent in the order, along with the current cost of the CPA. After an agent completes assigning all values in the domain to his variable, he backtracks, i.e., he sends the CPA back to the preceding agent. To prevent exhaustive traversal of the entire search space, the agents maintain an upper bound, which is the cost of the best solution that was found thus far. The algorithm keeps comparing the costs of CPAs and the current upper bound, in order to prune the search space.

Herein we devise a secure implementation of SyncBB, called PC-SyncBB (Privacy-preserving and Collusion-resistant SyncBB). Another secure implementation of SyncBB, called P-SyncBB, was previously introduced by Grinshpoun and Tassa GT14,GT16. The two algorithms are fundamentally different. While in P-SyncBB agents are exposed to sensitive information such as assignments of other agents, costs of CPAs, and the value of the upper bound, PC-SyncBB totally avoids such information disclosure. Hence, the outline of PC-SyncBB is simpler than that of P-SyncBB, because there is no need to implement mechanisms for preventing illegal inferences that can be deduced from such information. On the other hand, as in PC-SyncBB much less information is revealed, and as PC-SyncBB is designed to be resistant to coalitions (while P-SyncBB’s security is jeopardized already when two agents collude), the secure multi-party computational tasks in PC-SyncBB are much harder. Hence, the cryptographic approach taken in PC-SyncBB is completely different, and it is much more involved than the corresponding one in P-SyncBB.

3.1 Preliminaries

General assumptions and notations. The design of PC-SyncBB is based on the following general assumptions:

(1) There is a static public ordering of the agents, .

(2) The upper bound on the cost of any possible solution is , and it is known to all agents. In addition, all agents agree upfront on an integer greater than .

(3) For every pair of indices , is a Boolean predicate that equals true iff and are constrained. Then, and are sets containing the indices of all agents that precede/follow in the order and whose variable is constrained with . We also let .

Value ordering. Each agent maintains two value orderings over his domain

. Each of those orderings can be described by a vector of length

. The first ordering, denoted , is fixed and known to all agents such that . Then if and are constrained, they can describe their constraint as a matrix of rows and columns, where the value in the -th row and -th column is


The second ordering, denoted , is generated at random by whenever he begins a new traversal over his domain. That ordering, which is kept secret from all other agents, determines the order in which that agent will scan the values in his domain during that stage of the search. Agent generates such an ordering each time a CPA is passed to him from the preceding agent .

Internal variables. Every agent maintains the following variables:

(1) is an array of length that holds additive shares in the cost of the CPA. Assume that agents and are constrained and that is applicable to the CPA. Then the cost of the CPA includes, as one of its addends, the value . In such a case and will both store random values in so that


If, on the other hand, is not applicable to the CPA (i.e. the CPA does not include or or both), then . In view of the above, the overall cost of the CPA, at any stage of the algorithm’s run, equals



holds an additive share in the upper bound (the cost of the best full assignment that was discovered thus far). Each such share is random and uniformly distributed over

. At any stage of the algorithm’s run,


(3) is a pointer to a value in the ordering . The current assignment to is given by .

(4) stores the assignment to in the currently best full assignment that was found thus far.

3.2 The PC-SyncBB algorithm

The PC-SyncBB algorithm is given in Algorithm 1, which we proceed to describe.

0:  init
1:   for all
3:  if  do
5:  else
7:     assign_CPA()
7:  assign_CPA
8:  if  do
9:     Generate a new random ordering of into
11:  if  do
12:     backtrack()
13:  else
15:     update_shares_in_CPA
16:     if  do
17:         if compare_CPA_cost_to_upper_bound() true do
18:            broadcast(NEW_OPTIMUM_FOUND)
19:         assign_CPA()
20:     else
21:         if compare_CPA_cost_to_upper_bound() false do
22:            assign_CPA()
23:         else
24:            send(CPA_MSG) to
24:  backtrack
25:  if  do
26:      for all
27:     send(ZERO_SHARE_MSG,) to for all
28:     send(BACKTRACK_MSG) to
29:  else
30:     broadcast(COMPLETE)
32:  (CPA_MSG) do
34:  assign_CPA()
34:  (ZERO_SHARE_MSG,) do
36:  assign_CPA()
36:  (COMPLETE) do
38:  Terminate
Algorithm 1 PC-SyncBB (executed by agent )

The procedure init. Every agent initializes all entries in his vector as well as to zero (Lines 1-2). Then, every agent , , initializes to zero, while initializes it to (Lines 3-6). Such settings imply that mod , in agreement with Eq. (4) (since the initial upper bound is set to ). Finally, the procedure init triggers the search by having call the procedure assign_CPA (Line 7).

The procedure assign_CPA. If this procedure is called when , it means that now begins a new traversal over his domain. Hence, in such a case he generates a new random ordering, , of (Lines 8-9). In order to move to the next value in , increments the pointer (Line 10). If becomes greater than it means that the domain was already fully scanned, so

performs the procedure backtrack (discussed below) in order to return the search torch back to the preceding agent

(Lines 11-12). Otherwise, assigns to (Line 14). Consequently, as has a new value, the CPA’s cost is changed, so new random shares of that cost must be computed. This is done by calling the sub-protocol update_shares_in_CPA (Line 15), which recomputes and , for all , so that the right-hand side of Eq. (3) equals the new CPA’s cost. (We discuss that sub-protocol in Section 3.3.)

We now separate the discussion according to the index of the operating agent. If , then a new full assignment is reached. It is needed to compare its cost, which equals mod , Eq. (3), to the current upper bound, mod , (Eq. (4)). This comparison must be done in a secure manner. To that end, invokes compare_CPA_cost_to_upper_bound (Line 17), a secure multi-party sub-protocol that we discuss in Section 3.4. It returns true if the cost of the current full assignment is lower than the upper bound, namely, if


and false otherwise. If the current full assignment does improve the upper bound, then broadcasts the message NEW_OPTIMUM_FOUND (Line 18). Upon receiving such a message, every agent stores the sum of his current shares, , in and he also stores the current assignment of in (Lines 31-32). Finally, whether the current full assignment is a new optimum or not, calls the procedure assign_CPA again in order to test the next value in his domain (Line 19).

If , the agents examine the possibility to prune the search space: they first check whether the CPA’s cost is already greater than or equal to the upper bound, by invoking compare_CPA_cost_to_upper_bound (Line 21). If it returns false then Eq. (5) does not hold, i.e., the cost of the CPA is already greater than or equal to the upper bound. In such a case there is no point in pursuing the current path in the search space, so calls the procedure assign_CPA again in order to test the next value in his domain (Line 22). Otherwise, passes the torch onward to (by sending him the message CPA_MSG in Line 24) in order to continue the search over CPAs with the current -prefix. When receives the message CPA_MSG, he zeroes the pointer to his domain , in order to start traversing all values in as possible extensions to the current -CPA, and then he calls the procedure assign_CPA (Lines 33-34).

The procedure backtrack. When agent , , executes the procedure backtrack, he does two things. First, he zeros all entries in (Line 26) and sends a ZERO_SHARE_MSG message, with his index , to all agents that precede him and are constrained with him (Line 27). Any such agent, upon receiving the ZERO_SHARE_
message, zeroes the relevant share in his own array (Line 35). As a result of the above two actions, Eq. (3) still holds for the reduced CPA that is obtained after this backtracking. Afterwards, sends a BACKTRACK_MSG message to (Line 28). When the latter receives that message, he calls assign_CPA in order to change the assignment of his variable to the next value in his domain and proceed the search with the new modified CPA (Line 36).

When performs backtrack, it means that he completed a traversal of , and, consequently, the entire search space () was scanned. Therefore, the algorithm terminates with the last optimum found being the global optimum. In such a case broadcasts the message COMPLETE (Line 30). When receiving such a message, every agent assigns to his variable the value (which was his assignment in the last optimal solution that was found) and then he terminates (Lines 37-38).

3.3 The sub-protocol update_shares_in_CPA

Before starting PC-SyncBB, each of the agents , , creates a key pair in a Paillier cipher [Paillier1999] and sends the corresponding public key to for all . Denote by the encryption function in ’s cipher and by the corresponding modulus. Then is a function from to and it is additively homomorphic, in the sense that for every two plaintexts and , , where addition is modulo and multiplication is modulo . The Paillier cipher is probabilistic, in the sense that the encryption function depends also on a random string (so that every plaintext has a large number of possible ciphertexts ). It is known to be semantically secure [Goldwasser and Micali1982].

After creating , computes a vector of length where and for all . It is important to compute the latter encryptions with independently selected random strings. Then, defines the vectors , for , where is a circular right-shift by one position of the vector entries. Hence, encrypts the vector where the 1 appears in the th entry, . Given the manner in which those vectors were computed and the probabilistic and semantic security properties of the Paillier cipher, a polynomially-bounded adversary who gets any random sequence of those vectors (i.e. ) will not be able to distinguish between the and the

entries in them (with a non-negligible probability of success).

We are now ready to describe the sub-protocol update_shares_in_CPA (Algorithm 2). It is triggered by whenever he assigns a new value to his variable, . When that happens, it is needed to update the shares of all agents so that the validity of Eq. (3) is maintained. The shares that should be modified in wake of such an assignment are and for all . Those shares will be modified so that, in view of Eq. (2), the sum of and , for any fixed , will equal for the current assignments of and (’s assignment equals , and it is passed to the sub-protocol as an input).

Assume that . Then the contribution of the pair and to the CPA is , where and (see Eq. (1)). Recall that does not know while does not know . In order to compute the new respective shares, and , so that Eq. (2) holds, these two agents perform the following computation.

When performed last time the procedure assign_CPA and set there the current assignment to , he called update_shares_in_CPA (Algorithm 2), see Line 15 in PC-SyncBB. In Line 8 of Algorithm 2 he sent to all agents in the vector which encodes his current assignment. Going back to the present, when executes update_shares_in_CPA he holds a vector that he received from for every . That vector equals , where is the index in in which the current assignment to is stored. Even though cannot infer from the current value of , he can still correctly update his shares vis-a-vis . To that end, he computes


where is the index of the entry in that holds – the current assignment to , and is a value selected uniformly at random (independently for each ) from . The key observation here is the following.

Lemma 3.1

The homomorphism of implies that .

Next, sends to who decrypts it and stores it in . In view of Lemma 3.1, obtains whereas sets (Algorithm 2, Lines 5-6). Those two uniformly random shares satisfy , which fulfils the required equality in Eq. (2).

The above described updates are carried out by and for all . After completing all those updates, the updated shares satisfy Eq. (3).

0:  , the index of the agent that invokes the procedure, and , ’s current assignment
1:  for all  do
2:      selects uniformly at random .
3:      computes as given in Eq. (6), where is the vector that received from in the last time.
4:      sends the computed to .
5:      sets .
6:      sets .
7:  if  do
8:      sends to all where the vector where is the index for which .
Algorithm 2 The sub-protocol update_shares_in_CPA

3.4 compare_CPA_cost_to_upper_bound

The sub-protocol compare_CPA_cost_to_upper_bound verifies the inequality in Eq. (5). Agent , , holds two integers modulo : and . The goal is to determine whether is smaller than or not.

To this end, we make use of a secure multi-party computation (MPC) protocol [Yao1982, Beaver et al.1990]. An MPC protocol for some function allows a set of distrustful parties , where possesses a private input , to compute , while preserving the privacy of the parties. Namely, at the end of the protocol the parties learn , but nothing beyond that on inputs of other parties. Almost all practical MPC protocols work with the underlying Boolean/Arithmetic circuit as the computational model. Therefore, to securely compute the function , the parties first need to agree on a Boolean/Arithmetic circuit that implements . The runtime of such computations depends on and the size of the circuit (the number of gates in it).

In PC-SyncBB, we managed to shrink the usage of a general purpose MPC protocol to the computation of Eq. (5). Specifically, we use the protocol of Ben-Efraim and Omri BO17 for the function where ’s input is and the function returns true if Eq. (5) holds and false otherwise.

The protocol of Ben-Efraim and Omri BO17 is secure under the assumption that less than parties collude. It proceeds in two phases, called “offline” and “online”. In the offline phase the parties do not yet know their inputs, but can prepare the raw materials required for the computation. The online phase begins once the parties know their inputs. In practice, this allows the parties to perform the offline phase in advance, even without having their inputs (or even knowing the domains), and perform the fast online phase once the inputs are ready. Due to page limitations, we defer the detailed description of this sub-protocol to the full version.

3.5 Properties of PC-SyncBB

The main properties of this algorithm are stated below.

Theorem 3.2

PC-SyncBB is complete and sound.

Proof. The completeness of PC-SyncBB follows from the exhaustive search structure. Only partial assignments whose cost reach the upper bound are not extended and therefore it is guaranteed that the algorithm finds an optimal solution. Termination also follows from the exhaustive structure of the Branch-and-Bound algorithm in which no partial assignment can be explored twice.

PC-SyncBB is sound, in the sense that it outputs a correct solution, as implied by the correctness of update_shares_in_
CPA (which guarantees that Eqs. (3) and (4) are always correct) and compare_CPA_cost_to_upper_bound (which guarantees the correctness of validating Eq. (5)).

Theorem 3.3

PC-SyncBB provides constraint-, topology-, and assignment/decision-privacy. Even if any subset of agents collude, where , they would not be able to infer information on (values or existence of) constraints between two agents outside the coalition, or on value assignments or final decisions of such agents.

Proof. The only way in which privacy can be breached is through the data which is transmitted between agents. In the main body of PC-SyncBB (Algorithm 1) the only data which the agents transmit between themselves are command messages. Those messages convey information only with regard to the sizes of the variable domains, , , but those domains are assumed to be publicly known anyway. Since the order in which each agent traverses his domain during the search is random and kept secret from all other agents, such messages do not include any information regarding the assignments, the final decisions, the constraints, or the constraint graph topology.

In addition to those command messages, information is exchanged also in the two sub-protocols. In update_shares_in_
CPA, the agent receives from every , where , his vector . That vector is computed by whenever he assigns a new value from his domain to . As each of those computations is made independently of previous computations, and as the Paillier cipher is semantically secure, cannot infer from any information on the current assignment of . Moreover, as sends the same vector to all agents , , upon their request, no coalition, of any size, can gain additional knowledge on ’s assignments. Another place in update_shares_in_CPA in which data is exchanged is in Line 4. There, agent sends to the value , which includes the -encryption of . Since is selected uniformly at random from , this value contains no information at all. Moreover, since selects in Line 3 an independent random for each , also here there is no point in performing coalitions.

As for the compare_CPA_cost_to_upper_bound sub-protocol, it is secure, under the assumption of honest majority, since it implements the Ben-Efraim-Omri protocol that was shown to be secure under that assumption [Ben-Efraim and Omri2017].

It is important to note that, like all preceding papers on privacy-preserving solution of DCOPs, our algorithm does not guarantee perfect privacy, as it may leak some very benign information on the constraint graph topology. While achieving perfect privacy is possible, in theory, in any multi-party computation, it is very hard to do so while maintaining practicality. Hence, in almost all studies that deal with privacy-preserving solutions of practical problems, one accepts benign information leakages.

4 Experimental evaluation

We begin by evaluating the runtime of the compare_CPA_cost_to_upper_bound sub-protocol, which is a central and computationally expensive part of PC-SyncBB. For efficiency and reproducibility we used the original implementation of Ben-Efraim and Omri BO17.222https://github.com/cryptobiu/Protocols/tree/master/Concrete_
The executions were over LAN with EC2 machines of type c5.large in Amazon’s North Virginia data center with every agent running on a separate machine. We measured performance for various values of , where (the maximum value of a single binary constraint) is set to 100. Hence, as the maximum cost of any solution is and is set to be the smallest power of 2 greater than , then fully determines and, consequently, also the size of the circuit that the protocol uses. Table 1 gives, for each , the bit-length of the agents’ inputs, the overall circuit size (number of gates), and the average runtimes over 100 executions for the offline and online phases of the protocol.

5 7 9 11 13 15 17 19
11 13 13 14 14 15 15 16
184 336 448 610 732 924 1056 1278
offline 6.7 12.4 20.2 32.3 47.2 72.0 94.3 135.3
online 0.51 0.85 1.3 1.6 2.4 2.5 2.7 3.6
Table 1: Bit length, circuit size and runtime (msecs) of the Ben-Efraim-Omri as a function of .

Now we turn to the runtime performance evaluation of the full PC-SyncBB algorithm. In order to asses the toll of privacy preservation, we compare PC-SyncBB (offline+online) to other algorithms that maintain the Branch & Bound structure – P-SyncBB [Grinshpoun and Tassa2016] that preserves privacy only under the assumption of non-colluding agents, and the basic insecure SyncBB [Hirayama and Yokoo1997]. We also present separately the online requirements of PC-SyncBB. The algorithms were implemented and executed in the AgentZero simulator [Lutati et al.2014], running on a hardware comprised of an Intel i7-6820HQ processor and 32GB memory, except for the calls to the compare_CPA_cost_to_upper_bound procedure that were executed on the machines from Amazon’s North Virginia data center, in order to simulate as realistically as possible a truly distributed environment. We followed the simulated time [Sultanik et al.2008] approach in all the subsequent experiments. The results are shown in a logarithmic scale and are the average over 50 problem instances (for each setting/benchmark).

The first benchmark consists of unstructured randomly generated DCOPs on which we perform two experiments. In the first experiment, presented in Figure 1, we fix the number of agents to and the domain sizes to 6, and vary the constraint density . (Using lower density values results in unconnected constraint graphs.) It is clear that constraint density only mildly affects the runtime performance of all the evaluated algorithms. However, the toll of privacy preservation is evidently high, with each layer of protection adding about two orders of magnitude to the runtime. Specifically, the online part of PC-SyncBB requires about one order of magnitude more time than P-SyncBB.

Figure 1: Varying (random DCOPs).

In the second experiment, shown in Figure 2, we fix the constraint density to and the domain sizes to 6, and vary the number of agents . Here and in the following scalability experiments we use a cutoff time of 30 minutes for online PC-SyncBB. It is clear that the number of agents has a major effect on the performance of all the evaluated algorithms, in accordance with known results regarding the scalability of Branch & Bound algorithms in computationally hard problems. Interestingly, P-SyncBB scales slightly better, probably due to its inherent use of sorted value ordering.

Figure 2: Varying (random DCOPs).

Similar scalability phenomena are also observed in more structured benchmarks. Figure 3 depicts the runtime performance on distributed 3-color graph coloring problems (, ) in which each pair of equal values of constrained agents imposes a random and private cost. The structure in these problems lies in the diagonal constraint matrices between every pair of neighboring agents.

Figure 4 presents the runtime performance on scale-free networks (, domains of size 5), which are structured networks that are generated according to the Barabási-Albert model [Barabási and Albert1999].

Figure 3: Varying (graph coloring problems).
Figure 4: Varying (scale-free networks).

5 Conclusion

We proposed herein PC-SyncBB, the first privacy-preserving DCOP algorithm which is secure against coalitions. We analyzed the properties of the algorithm and evaluated its performance. Our experiments demonstrate that PC-SyncBB is feasible for moderately-sized problems.

A major limitation on scalability is due to the protocol of Ben-Efraim and Omri BO17 that is invoked by compare_CPA_cost_to_upper_bound. In the future we intend to explore other directions that could yield much more efficient implementations of that sub-protocol. If those constructions prove more efficient, we intend to consider more challenging settings, with larger coalitions or malicious agents. While raising the security bar usually increases runtime and communication costs, it is important to come up with such solutions in order to enlarge and diversify the toolkit available for implementations in various application settings. Finally, as all existing privacy-preserving DCOP algorithms base their security on assuming solitary conduct of the agents, we view this study as an essential first step towards lifting this potentially harmful assumption in all those algorithms. In particular, it is necessary to develop privacy-preserving and collision-secure implementations of other DCOP algorithms (e.g., inference-based), and especially of incomplete algorithms that could offer better scalability.


  • [Barabási and Albert1999] Albert-László Barabási and Réka Albert. Emergence of scaling in random networks. Science, 286(5439):509–512, 1999.
  • [Beaver et al.1990] D. Beaver, S. Micali, and P. Rogaway. The round complexity of secure protocols. In STOC, pages 503–513, 1990.
  • [Ben-Efraim and Omri2017] A. Ben-Efraim and E. Omri. Concrete efficiency improvements for multiparty garbling with an honest majority. In LATINCRYPT, 2017.
  • [Ben-Or et al.1988] Michael Ben-Or, Shafi Goldwasser, and Avi Wigderson. Completeness theorems for non-cryptographic fault-tolerant distributed computation. In STOC, pages 1–10, 1988.
  • [Farinelli et al.2008] A. Farinelli, A. Rogers, A. Petcu, and N.R. Jennings. Decentralised coordination of low-power embedded devices using the max-sum algorithm. In AAMAS, pages 639–646, 2008.
  • [Gershman et al.2009] A. Gershman, A. Meisels, and R. Zivan. Asynchronous forward bounding for distributed COPs.

    Journal of Artificial Intelligence Research

    , 34:61–88, 2009.
  • [Goldwasser and Micali1982] S. Goldwasser and S. Micali. Probabilistic encryption and how to play mental poker keeping secret all partial information. In STOC, pages 365–377, 1982.
  • [Greenstadt et al.2007] R. Greenstadt, B. Grosz, and M.D. Smith. SSDPOP: improving the privacy of DCOP with secret sharing. In AAMAS, pages 171:1–171:3, 2007.
  • [Grinshpoun and Tassa2014] T. Grinshpoun and T. Tassa. A privacy-preserving algorithm for distributed constraint optimization. In AAMAS, pages 909–916, 2014.
  • [Grinshpoun and Tassa2016] T. Grinshpoun and T. Tassa. P-SyncBB: A privacy preserving branch and bound DCOP algorithm. Journal of Artificial Intelligence Research, 57:621–660, 2016.
  • [Grinshpoun et al.2019] Tal Grinshpoun, Tamir Tassa, Vadim Levit, and Roie Zivan. Privacy preserving region optimal algorithms for symmetric and asymmetric DCOPs. Artificial Intelligence, 266:27–50, 2019.
  • [Hirayama and Yokoo1997] K. Hirayama and M. Yokoo. Distributed partial constraint satisfaction problem. In CP, pages 222–236, 1997.
  • [Katagishi and Pearce2007] H. Katagishi and J.P. Pearce. Kopt: Distributed DCOP algorithm for arbitrary k-optima with monotonically increasing utility. In DCR, 2007.
  • [Léauté and Faltings2013] Thomas Léauté and Boi Faltings. Protecting privacy through distributed computation in multi-agent decision making. Journal of Artificial Intelligence Research, 47:649–695, 2013.
  • [Lezama et al.2017] F. Lezama, J. Palominos, A.Y. Rodríguez-González, A. Farinelli, and E. Munoz de Cote. Agent-based microgrid scheduling: An ICT perspective. Mobile Networks and Applications, 2017.
  • [Lutati et al.2014] Benny Lutati, Inna Gontmakher, Michael Lando, Arnon Netzer, Amnon Meisels, and Alon Grubshtein. Agentzero: A framework for simulating and evaluating multi-agent algorithms. In Agent-Oriented Software Engineering, pages 309–327. Springer, 2014.
  • [Maheswaran et al.2004] R.T. Maheswaran, M. Tambe, E. Bowring, J.P. Pearce, and P. Varakantham. Taking DCOP to the real world: Efficient complete solutions for distributed multi-event scheduling. In AAMAS, pages 310–317, 2004.
  • [Mailler and Lesser2004] R. Mailler and V.R. Lesser. Solving distributed constraint optimization problems using cooperative mediation. In AAMAS, pages 438–445, 2004.
  • [Meseguer and Larrosa1995] P. Meseguer and J. Larrosa. Constraint satisfaction as global optimization. In IJCAI, pages 579–584, 1995.
  • [Modi et al.2005] P.J. Modi, W.M. Shen, M. Tambe, and M. Yokoo. ADOPT: asynchronous distributed constraint optimization with quality guarantees. Artificial Intelligence, 161:149–180, 2005.
  • [Ottens et al.2017] B. Ottens, C. Dimitrakakis, and B. Faltings. Duct: An upper confidence bound approach to distributed constraint optimization problems. ACM Transactions on Intelligent Systems and Technology (TIST), 8(5):69, 2017.
  • [Paillier1999] P. Paillier. Public-key cryptosystems based on composite degree residuosity classes. In Eurocrypt, pages 223–238, 1999.
  • [Petcu and Faltings2005] A. Petcu and B. Faltings. A scalable method for multiagent constraint optimization. In IJCAI, pages 266–271, 2005.
  • [Silaghi and Mitra2004] M.C. Silaghi and D. Mitra. Distributed constraint satisfaction and optimization with privacy enforcement. In IAT, pages 531–535, 2004.
  • [Sultanik et al.2008] E. Sultanik, R. N. Lass, and W. C. Regli. DCOPolis: a framework for simulating and deploying distributed constraint reasoning algorithms. In AAMAS (demos), pages 1667–1668, 2008.
  • [Tassa et al.2017] T. Tassa, T. Grinshpoun, and R. Zivan. Privacy preserving implementation of the Max-Sum algorithm and its variants. Journal of Artificial Intelligence Research, 59:311–349, 2017.
  • [Yao1982] A.C. Yao. Protocols for secure computation. In FOCS, pages 160–164, 1982.
  • [Yeoh et al.2010] W. Yeoh, A. Felner, and S. Koenig. BnB-ADOPT: An asynchronous branch-and-bound DCOP algorithm. Journal of Artificial Intelligence Research, 38:85–133, 2010.
  • [Zhang et al.2005] W. Zhang, G. Wang, Z. Xing, and L. Wittenburg. Distributed stochastic search and distributed breakout: properties, comparison and applications to constraint optimization problems in sensor networks. Artificial Intelligence, 161(1-2):55–87, 2005.