## 7 Overhead Analysis  
To evaluate the efficiency of the proposed approach, we conducted several simulations, varying the key parameters that influence performance. The overall performance of the system was measured by tracking the execution time for the main operations required by our approach. The measurements were performed by running a Python simulation on a personal computer equipped with a 2.8 GHz Intel i7-1165G7 CPU and 16 GB of RAM. The obtained results are reported in Table 2.  
We now discuss the timings resulting from our simulations by examining the operations executed on the publisher side and the subscriber side. On the publisher side, the overhead required by our solution consists first of the selection of \(k\) parties and then of the computation of the length for each part. It is observed that the operations performed by the publisher typically require times on the order of tens of microseconds, multiplied by the number of parts \(k\). Specifically, the selection of the \(k\) parts involves randomly extracting \(k-1\) parts and then computing the \(k\)-th part as the XOR of all the other parts and the message to be transmitted. In contrast, the length computation operation involves calculating \(k\) message lengths to be transmitted (through exponentiation operations). Moreover, the number of parts \(k\) determines the number of brokers where the parts are published. The higher this number, the more brokers would need to collude to reconstruct the final message. However, selecting a value of \(k\) in the range of about ten parts is typically sufficient to ensure that these randomly selected brokers do not all collude. Therefore, it can be concluded that the operations on the publisher's side are efficient, with negligible overhead. On the subscriber's side, two main operations are involved: the setup phase and the message reconstruction. Message reconstruction is highly efficient, typically requiring times on the order of tens of microseconds multiplied by the number of parts \(k\), as it consists only of XORing the parts recovered from the \(k\) brokers. On the other hand, the setup operation (which involves generating the lengths corresponding to all possible parts--essentially a brute-force operation over all possible parts) has times that grow exponentially with the \begin{table}
\begin{tabular}{c c c} \hline \hline  & **Operations** & **Execution Time** \\ \hline Publisher side & Selection of \(k\) parts & 0.908 \(\mu s*k\) \\  & Length computation & 1.997 \(\mu s*k\) \\ \hline Subscriber side & Setup phase & 27.8 s (for 20 bits) \\  & Message reconstruction & 0.823 \(\mu s*k\) \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Execution time of the main operations required for our approach. number of bits in the message. As shown in the table, if the message has 20 bits, the time required is on the order of seconds. It is important to note that while the setup operation takes longer, it is a one-time process, as it is used to precompute the possible message lengths. In conclusion, we discuss the overhead introduced by our solution in terms of the transmitted bytes. Recall that \(M\) represents the message to be reconstructed, whereas the actual transmitted messages are those whose lengths depend on the values of the selected parts. In the example shown in Section 6, for transmitting the message \(M=\)\"\(H\)\" with \(k=3\), three messages of lengths \(264,313,832,89,686,678,\) and \(144,660,972\) bytes are transmitted. To estimate the average length of the messages sent, we conducted a simulation where, over 10,000 runs, we varied the modulus \(n\) and the exponent \(a\) while keeping the message length \(|M|=8\) bits. Figure 3 shows how the computed lengths are distributed based on the simulation. It can be observed that the distribution of lengths is uniform in the range from 0 to \(268,435,456\) bytes. Due to the properties of a uniform distribution, the average length of the transmitted messages is approximately \(134,217,728\) bytes.