# Binary-Tree-Fed Mixnet: An Efficient Symmetric Encryption Solution
## 5 Results and Discussion  
This section describes a series of experiments aimed at assessing the differences regarding BTFM with other schemes. Firstly, it is compared with asymmetric systems (RSA and cMIX) and then with ESEBM. The first graph meets the objective of contextualizing purely symmetric systems with respect to traditional schemes (RSA), including one of the most advanced in terms of speed, such as cMIX. The following charts show cases in which BTFM and ESEBM clearly differ in delay and header size.  
The following results have been obtained using a CPU i5-3230M, at 2.6 GHz and 16 GB of RAM. The software has been developed on Java 1.8\(0\)121 in a Windows 10 OS. The message length has been chosen to be 1024 bits. It must be the same for any key. However, for labels (\(q_{ij}\) in ESEBM and \(L_{ij}\) in BFTM), an integer (32 bits) has been selected. Network delays are not considered. With this scenario, a mixnet of ten nodes throws an average node delay shown in Figure 5. The batch size varies from 1000 to 10,000 users. Each line corresponds to one of the four schemes: a decryption mixnet based on RSA, cMIX (modular products), ESEBM, and BTFM. As can be seen, symmetric mixnets are very similar with the lowest latency. However, RSA and cMIX present a significantly higher delay. In fact, for 10,000 users, RSA is 91 times slower than BTFM, cMIX 30 times, and ESEBM 1.6 times.  
In order to appreciate the differences between BTFM and ESEBM, the batch size must be increased. The considerable reduction offered by BTFM can be seen in Figure 6. In the first case (100 K users), BTFM takes almost half (50.8%) the time of ESBM. This difference increases as the number of users grows, to the point that with 550 K users it reaches 23.6%. That is, BTFM is 4.2 times faster than ESEBM in this case. A deeper look reveals that the XORing time is very reduced in both schemes (4.2% of total time in BTFM and 1.6% in ESEBM). Permutation and serialization operations are the most time-consuming.  
In ESEBM, the batch size is significantly larger than in BTFM because a label vector proportional to the size of the mixnet must be added. Figure 7 shows this exceedance of the BTFM batch in two ways: megabytes in columns and percentages in a line. The mixnet size, from 10 nodes to 100, is represented on the abscissa. In ordinates, the same number represents the percentage and the overload megabytes. This chart corresponds to 250 K users. However, if the number of users with the same mixnet size is varied, horizontal lines are observed. That is, the percentage that represents the excess of the batch size remains constant with respect to users. Regarding the nodes, the worst case (100 nodes) presents an overload of 100.1 MB (39.6%).  
Figure 5: Node delay comparison among RSA, cMIX, ESEBM, and BTFM mixnets.  
Figure 6: Delay in an ESEBM node (continuous line) and in a BTFM node (dots).  
Overall, in light of these experiments, the performance of BTFM stands out from other systems. It is overwhelmingly superior to asymmetric encryption systems (up to 30 times faster), it slightly improves ESEBM in low-demand environments (batches of 10.000 users), and clearly surpasses it when demand increases (doubles it from 100,000 users). Furthermore, messages do not increase in size by aggregating headers as in ESEBM, which implies a reduction in the time to send batches between nodes.