# Wireless and Fiber-Based Post-Quantum-Cryptography-Secured IPsec Tunnel
## 6 Results  
### Signature Algorithms  
Figure 4 shows the methodology that we use for setting up the quantum-secure IPsec tunnel that we present in this work. The server machine and the client machine have to perform different tasks. As Dilithium and Falcon are signature algorithms, they are part of step 2 in Figure 4. Hence, the latency introduced by the execution of the algorithms can be attributed to step 2. While executing a signature algorithm, the server machine needs to generate a key and create a signature using the sign process. Figure 8 shows the average required clock cycles while executing Dilithium on the server side on the server directly (blue background), on the Jetson (red background), and on the DPU (yellow background). While signing, a security downgrade from Dilithium 5 down to Dilithium 3 comes with a performance gain between 6 % (server) and 39 % (DPU) in terms of CPU cycles. Further trading off security for the velocity of execution by using Dilithium 2 instead of 5 yields a performance boost between 41 % (server) and 89 % (DPU). While generating a key, it is between 35 % (server) and 40 % (Jetson) faster to use Dilithium 3 instead of Dilithium 5. At the lowest security level, it consumes 89 % (server, Jetson, and DPU) less CPU cycles to use Dilithium 2 instead of Dilithium 5.  
The cryptographic operations of Dilithium's client side are shown in Figure 9. The client needs only to verify the signature. The verification process of a Dilithium 5 signature takes between 25 % (server) and 43 % (Jetson) longer than the verification of a Dilithium 3 signature. Verifying a Dilithium 2 signature is between 65 % (server) and 83 % quicker than the equivalent process for a Dilithium 5 signature.  
The cryptographic latency introduced by Falcon on the server side can be seen in Figure 10. Generating a key for Falcon 1024 takes between 89 % (Jetson) and 94 % (server) more clock cycles in comparison with Falcon 512. It is of note that the key generation of Falcon is particularly more challenging than Dilithium's key generation. Falcon's key generation requires about two orders of magnitude more clock cycles compared to Dilithium's key generation. Signing requires between 63 % (server) and 73 % (DPU) more clock cycles for Falcon 1024 while comparing it with Falcon 512.  
Figure 7: Wireless setup: An Nvidia Jetson Nano connects to a WiFi using a WiFi antenna extension. The Jetson establishes a PQC-secured IPsec tunnel and connects through the network to a server that is equipped with a 25G DPU.  
The cryptographic latency introduced by Falcon on the client side can be seen in Figure 11. The client requires between 54 % (Jetson) and 71 % (DPU) more clock cycles to verify a Falcon 1024 signature compared to a Falcon 512 signature. Falcon's and Dilithium's verification processes are similarly competitive in terms of performance. Dilithium is slightly faster while Falcon is within the same order of magnitude regarding the required CPU clock cycles for the execution.  
Figure 8: Cryptographic latency introduced by the execution of Dilithium’s keygen and Dilithium’s sign executed on the server side. The server device was a Dell PowerEdge server, equipped with an Intel Xeon CPU, an NVIDIA Jetson (the wireless device in our setup), and an NVIDIA BlueField 2 DPU.  
Figure 9: Cryptographic latency introduced by the execution of Dilithium’s verification executed on the client side. The server device was a Dell PowerEdge server, equipped with an Intel Xeon CPU, an NVIDIA Jetson (the wireless device in our setup), and an NVIDIA BlueField 2 DPU.