# Empirical Study of Fully Homomorphic Encryption Using Microsoft SEAL
## 4 Results
In this scenario and with 10,000 samples, a 100% peak load is reached due to the complexity of the run. Finally, for a degree value of 32,768, the load in the first run averages 75%, except for 10,000 samples where it peaks at 100%. In the second run, it oscillates between 30% and 40% up to sets of 100 samples. For 1000 samples, 100% is reached in some parts of the run. For a larger set size, it is not possible to carry out the execution due to the increased complexity and memory demand. As we have seen, the impact of caching between the first and second runs is notable. This effect is due to the compilation of the code, configuration of the encryption parameters, and initialization of cryptographic contexts and keys. Once these operations are executed, some elements such as compiled code and key structures are cached, enabling faster access and reduced CPU load in later runs. Additionally, operating systems and runtime environments may optimize memory management and execution paths based on previous operations, enhancing performance efficiency. In the first run across various configurations, the CPU load was relatively high as the system compiled and configured the encryption setup. For example, with a _poly_modulus_degree_ of 1024 (Figure 2, white arrow), the CPU load averaged around 70%. However, in the second run, the CPU load markedly decreased. For large datasets (10,000 samples), the load dropped from near maximum capacity in the first run to about 30% in the second run, showing a substantial reduction. This reduction in CPU load in the second run indicates that the system benefits from caching, which could  
Figure 4: CPU load using a _poly_modulus_degree_ of 16,384 for 1000 samples; white arrows show the first execution and red arrows mark the second execution. Figure 3: CPU load using a _poly_modulus_degree_ of 8192; white arrows show the first execution and red arrows mark the second execution: (**a**) 1 and 10 samples; (**b**) 100 and 1000 samples; (**c**) 10,000 samples, first execution; (**d**) 10,000 samples, second execution. include optimized access to frequently used data or compiled code, in turn resulting in faster execution times and lower resource usage in successive runs. The second batch of experiments was carried out on a Jetson Nano. The exploration of homomorphic encryption performance on the Jetson Nano provides a distinct perspective on the applicability and scalability of cryptographic practices in edge computing environments. Given the inherent resource constraints of devices like the Jetson Nano, this analysis not only benchmarks the operational efficiency of homomorphic encryption but also delineates the potential for deployment in IoT ecosystems. The Jetson Nano Developer Kit by NVIDIA has a quad-core ARM Cortex-A57 processor, 128-core Maxwell GPU, and 4 GB LPDDR4 RAM. The configuration involved setting up the environment with JetPack, flashing the system image, and installing the Microsoft SEAL library and monitoring tools like _htop_ for system utilization visualization. The critical parameters under investigation mirrored those of the previous PC-based tests, emphasizing dataset size and the _poly_modulus_degree_ within the BFV encryption scheme. The analysis began with an examination of execution times across varying dataset sizes and _poly_modulus_degree_ values. The execution time on the Jetson Nano exhibited a pronounced increase with larger datasets and higher degrees, similar to observations made on the PC (see Figure 5). However, distinct disparities emerged as the dataset size expanded. For smaller datasets (1, 10 samples), the execution times were comparatively lower on the Jetson Nano than on the PC, suggesting an efficient utilization of the Nano's processing capabilities for lightweight cryptographic tasks. As the dataset size increased to 100 samples, a tipping point was observed where the execution time on the Jetson Nano began to lag significantly behind the PC's performance, underscoring the impact of limited computational resources.