# Enabling Horizontal Collaboration in Logistics Through Secure Multi-Party Computation
## 4 Toward an MPC-Based Solution for the CFDP
### Security Consideration  
By the definition of security for multi-party computation [16; 17; 18; 19; 20; 21; 22; 23], it is guaranteed that no information beyond the defined computation outputs is revealed to any participant in the system. Assuming a software framework that securely implements these protocols, we thus only need to argue that the data explicitly revealed to the computing nodes during the protocol execution does not contain any sensitive information. **Assigned orders. **: At the end of the output phase, Protocol 3 discloses a full description of the truck drives assigned to a specific haulier only to this party, i.e., each haulier learnsthe orders that it is responsible for. This is an immediate functional requirement and the expected output of the computation, and thus does not violate confidentiality. It should also be observed that repeated executions of the protocol could reveal recurring patterns in order volumes and routes, and in the matching between orders and trucks. There does not seem to be an obvious solution to this issue, since hualiers _have_ to know which orders are assigned to which trucks, and hiding these patterns would arguably require adding some form of noise or randomization, which would degrade the quality of the solution. This, however, is an inherent issue of the CFDP problem itself and is thus orthogonal to the goals of our solution; moreover, as argued in Section 3.3, our solution is arguably best suited for a setting where most of the orders have already been individually processed by each hualier with separate, in-house optimization, and where only a limited total number of orders (in the order of a few thousands) is left to be processed. Hence, the revealed patterns would only concern a fraction of the number of orders submitted to the hualiers. **Number of orders and empty drives per hualier. **: Similarly, Protocol 3 explicitly outputs the number of empty drives as well as the number of orders per hualier to all participants, but no information about the specific orders to be processed or their origins/destinations. Initial discussions with domain experts showed that (average case) fairness is one of the key features requested by hualiers, e.g., to ensure that no systematic biases (e.g., with a specific hualier systematically getting more empty rides than another) in case of malicious computing nodes exist. This request is addressed by outputting such audit information, without violating the confidentiality of sensitive information. At the same time, this output helps to increase efficiency, as otherwise \"fake\" orders and truck drive objects would need to be created to mask the actual number of orders and empty drives of each hualier. Given that this is a functional requirement for certain stakeholders as well as an efficiency booster, we therefore chose to reveal this piece of information. **Number of processed orders per iteration. **: During each iteration of the solver, the number of orders processed during this iteration is revealed (Step 2 of the computation phase). This could be avoided, but it would lead to a very inefficient oblivious while-loop construction, where we would need to set an upper bound on the number of iterations necessary to obtain a solution (roughly \(2\cdot|\)orderSet\(|\) as in the worst case every single order would cause an empty truck drive before it can be processed), and then run each iteration for this fixed number of times, accepting the worst-case complexity for every given instance, while our experiments show that significantly better average-case performance can be achieved (cf. Section 4.4). However, arguably, this piece of information does not reveal sensitive data, as it neither includes the number of truck rides nor information about origins, destinations, or owners of orders. Rather, it solely reveals a single inequality on the relative distribution of trucks, orders, and order sizes (basically indicating that no remaining order would fit into any truck), which does not allow one to infer information about single orders.