# Privately Generated Key Pairs for Post Quantum Cryptography in a Distributed Network
## 4 Experimental Validation  
The proposed protocol was validated with an SRAM-based PUF token provided by Castle Shield Holdings, LLC, Scottsville, VA, USA [30]. For the root of trust, see Figure 8. The token was manufactured with STM32F401 RBT MCU and IS61 LV6416 SRAM and had 44 TSOP pin packages. Each SRAM had 65,536K words, which gave access to 1,048,576 bits that were unique; 256 of them were randomly selected during each key generation to obtain seed \(a_{1}\). In this implementation, Crystals-Dilithium 2 was selected, which has 1312-byte-long public keys and 2420-byte-long signatures [31]. In total 20,000 verification cycles were run  
Figure 8: SRAM-based PUF token developed by Castle Shield, LLC. Figure 7: Implementation with multifactor authentication and root of trust with biometry. with the protocol, with a success rate of 100%. An upper bound of 45 s for each test cycle was set. The Inter(R) Core (TM) i9-9900K CPUY @ 3.160 Ghz processor was used for the test. The Ternary Addressable Public Key Infrastructure (TAPKI) protocol was an integral part of the verification of the root of trust [29]. The TAPKI server sent the challenges to the token in the form of a handshake. Four different handshake sizes were used in the test: 1024 bit, 1280 bit, 1536 bit, and 1792 bit. We found that handshake size did not have much of an impact on the overall protocol performance. So, in this paper, the reporting is based on a 1024 bit handshake size (see Figure 9). The integration of fragmentation, which is a technique to improve latency and security with the assistance of a masking scheme for Response-based Error Correction (RBC), was integrated [32]. In RBC, an error correction process can be applied to the hashed key and fix errors to a certain level to recover the correct key. A fragmentation scheme was designed to create subkeys out of the full key as, during the key recovery process, this reduced exponentially the search space for each subkey, eventually leading to decreasing latencies for the server. However, there should be a limit to the fragmentation level, as too much fragmentation has a negative impact on latencies for client devices. With 256 bit long keys and a fragmentation level of 16, the client devices used nonces to generate sixteen 256 bit length subkeys, hash them, and transmit the message digests to the server equipped with the RBC search engine. There was a trade-off as no fragmentation was prohibitive for the server, and excessive fragmentation slowed down the client devices. The distribution of errors from the token is shown in Figure 9, with four different handshake sizes and five different fragmentation levels (1, 2, 4, 8, 16), making 20,000 verification cycles. For fragmentation level 1, no subkeys were created, but only three errors could be processed: the time to find the correct key rose exponentially and the 45 s threshold setup for the test eliminated the cases with more than three errors. Fragmentation levels 2 4, 8, and 16 showed a similar pattern of error distribution: errors 0, 1, and 2 consisted of more than 72% of the errors, while more than 24% of the errors came from errors 3 and 4; errors  
Figure 9: Error distribution for different fragmentation levels. 5, 6, 7, and 8 were less frequent. Figure 10 shows the impact of fragmentation of overall latency on the RBC key recovery scheme. The time complexity of the RBC error correction scheme was \(2^{N}\) for no fragmentation, where \(N\) is the length of the key, and it had to try all possible combinations for the worst case. However, fragmentation scaled down the time complexity of the error correction scheme by \(2^{N/K}\), where \(K\) is the fragmentation level for the worst case. Fragmentation level 16 was the optimal solution for the server; however, the burden on light client devices was a problem. From Figure 10, we can observe that the average latency difference between fragmentation levels 2 and 4 was 236.68 ms. The difference between fragmentation levels 4 and 16 was 38.54 ms.