# A Secure Median Implementation for the Federated Secure Computing Architecture
## 3 Materials and Methods
### Implementation
Figure 5: Runtime as a function of varying number of parties for datasets of differing range with fixed size of \(10^{2}\) (**a**) and differing size with fixed range \(10^{2}\) (**b**) on a laptop with local set up. ## 5 Discussion

In our research, we have successfully implemented and performed a real-world benchmarking of a specialized protocol for the computation of rank-based statistics, with a focus on the median, as developed by [PERSON] et al. [10]. We have provided much-needed benchmarking and real-world evaluation of this protocol, demonstrating its viability and effectiveness in practical applications, a prerequisite for real-world settings, including medical research. In particular, we show that the protocol scales well with increasing data size up to \(10^{6}\) entries, maintaining runtimes between 1 and 4 s, ignoring network overhead. However, for larger datasets (>10\({}^{7}\) entries), the exponential growth in runtime (>15 s) highlights the need for optimization when dealing with very large datasets. Possible solutions include parallelization of processes running locally within each stage on each server or increasing computing resources. Moreover, our analysis indicates a linear growth in runtime as the number of parties increases, evident in both fixed-size and fixed-range experiments. This suggests that the protocol's efficiency remains manageable even with additional parties, as the runtime consistently remains below one minute for scenarios involving up to ten parties. Such settings are common in fields like biomedical research, e.g., where a few hospitals contribute to a multicentric study and jointly want to compute statistics over their databases without revealing individual inputs. However, for scenarios involving a larger number of parties with only a few data points, a central server model, such as the star network described in [7; 8], may be more suitable. This model involves all parties communicating with a central party, reducing communication costs and offloading complex computations to the central untrusted party. Notably, [PERSON] et al. [8] demonstrated that for 100 parties, each holding one data point, the runtime can be reduced to under a minute, provided the central party has sufficient computing power (32 GB RAM in their example). Nevertheless, the runtime in our experiments using AWS EC2 instances was dominated by networking overhead. The instances kept minimal and unoptimized were limited to AWS free tier (EC2 t2.micro), classified as \"low to moderate\" by AWS [24]. This is evident from the measured RTT of up to 22 ms between AWS instances, highlighting the importance of minimizing latency in distributed MPC setups. [PERSON] and [PERSON] [9] demonstrated significantly lower runtimes of 1 to 2 s for their differentially private median algorithm with RTTs of 12-25 ms, though comparisons are challenging due to their purpose-optimized implementation. Additionally, we benchmarked our implementation using real-world datasets to demonstrate its practical applicability in medical research. Networking overhead significantly increases runtime, especially for the heart disease dataset (from 16 to 17 s locally to over 800 s with AWS regions), highlighting the need for strategic resource selection. Despite this, the protocol's performance on real-world data shows its deployment potential, particularly when network latency is minimized. ### Security Analysis

The security of the underlying secure median algorithm has been demonstrated by [PERSON] et al. [10]. They address both semi-honest parties, who adhere to the protocol but seek to gain additional information and malicious adversaries, who may deviate from the protocol and provide fabricated inputs. While they propose additional steps to extend security to the malicious case, our implementation currently supports only the semi-honest case. A primary weakness in our setting occurs when one of two parties, or all but one