# Wireless and Fiber-Based Post-Quantum-Cryptography-Secured IPsec Tunnel
## 4 Implementation
### Algorithmic Procedure  
We use the procedure shown in Figure 4 to set up the IPsec tunnel that we present in this work. First, we establish an OpenSSL ([[https://www.openssl.org/](https://www.openssl.org/)]([https://www.openssl.org/](https://www.openssl.org/)) accessed on 10 January 2024) connection between the two devices. The cipher that we used for the OpenSSL session is TLS_AES_256_GCM_SHA384. The required certificates are self-signed. In a real-life scenario, the self-signed certificates would need to be replaced by certificates issued by a certificate authority. The second step is the exchange of PQC signatures. For this purpose, we use the reference implementation of Falcon [14] and the reference implementation of Dilithium [15]. After that, we exchange a PQC key using Kyber's reference implementation [16]. The reference implementations of the three PQC algorithms used in this work are available online ([[https://falcon-sign.info/](https://falcon-sign.info/)]([https://falcon-sign.info/](https://falcon-sign.info/)), [[https://pq-crystals.org/dilithium/index.shtml](https://pq-crystals.org/dilithium/index.shtml)]([https://pq-crystals.org/dilithium/index.shtml](https://pq-crystals.org/dilithium/index.shtml)), [[https://pq-crystals.org/kyber/index.shtml](https://pq-crystals.org/kyber/index.shtml)]([https://pq-crystals.org/kyber/index.shtml](https://pq-crystals.org/kyber/index.shtml)) accessed on 10 January 2024). The fourth step is the combination of the OpenSSL key with the PQC key by performing an XOR operation with the OpenSSL key and the PQC key. This is called key mixing. The resulting key is secure for as long as at least one of the two mixed keys is not compromised [46]. Ultimately, we use the ephemeral key resulting from mixing the keys to set up the IPsec connection using the pre-shared key method. The IPsec connection is protected by AES-256 GCM encryption which is considered to be secure against quantum attacks [7]. Superuser privileges are required for the execution. The session key remains active for as long as the IPsec SA is active. In case a new key needs to be exchanged, the procedure shown in Figure 4 is repeated.  
Figure 4: Methodology: First, using self-signed certificates, an OpenSSL session is established. The used cipher was TLS_AES_256_GCM_SHA384. Then, PQC signatures are exchanged. As a third step, Kyber is used to exchange a key. Fourthly, the key retrieved by Kyber and the key established by the OpenSSL session are mixed. Ultimately, an IPsec tunnel is set up using the mixed ephemeral key.  
We execute the procedure shown in Figure 4 on the server machine's processor directly, on the DPU, and on the Jetson. If the cryptographic operations are executed on the server's CPU, the DPU is used as simple NIC. The server encrypts the traffic and sends the outgoing traffic already encrypted to the NIC via PCIe 4. While receiving traffic, the NIC forwards the encrypted traffic to the host, and the host machine decrypts the traffic on its own CPU. In this case, the NIC only manages outgoing and incoming connections. It is not used for processing of any kind. If the cryptographic are executed on the NIC, the server sends the outgoing and incoming traffic unencryptedly to the NIC. It thus saves valuable CPU cycles of its own CPU. In this case, the NIC executes all cryptographic operations. It receives the data as plaintext from its host and sends out the data encryptedly. The receiving DPU decrypts the incoming packets and forwards them to the host via PCIe 4.