# Post Quantum Cryptographic Keys Generated with Physical Unclonable Functions
## 5 Experimental Evaluation
### Experimental Methodology  
As of the time of writing, there are few implementations of RBC engines proposed. In this paper, we focus on executing the RBC protocol on a single machine equipped with multi-core CPUs. Our implementations are parallelized using OpenMP. To terminate the search when a thread finds the correct key, we use a flag in shared memory that is \begin{table}
\begin{tabular}{c c c c c} \hline \hline
**Algorithm** & **Parameter Set** &
\begin{tabular}{c} **NIST** \\ **Candidate** \\ \end{tabular} & **Instructions** & **Selection Reason** \\ \hline AES & AES256 & N/A & AES-NI, SSE & Benchmark: HW implementation \\  & & & & Lacks DSA and KEM capabilities \\ ECC & Secp256r1 & N/A & AVX, SSE & Benchmark: mainstream for PKI \\  & & & & Uses 256-bit long keys for DSA \\ qTESLA & p-I & Dropped & AVX, SSE & PQC dropped by NIST: too slow \\ CRYSTALS- & & & & DSA uses relatively small keys \\ Dilithium & & & & Active LWE PQC algorithm \\  & & & & One of preferred DSA scheme \\ SABER & LightSABER & Phase 3 & AVX, SSE & Active LWR PQC algorithm \\  & & & & One of the preferred KEM scheme \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Selected cryptosystems, parameter sets, whether the PQC algorithms are NIST round 3 candidates, specialized instructions employed in the implementations, and our motivation for selecting the algorithm and its configuration. atomically updated. All implementations utilized the same overall structure and key iteration mechanism. We also use AVX instructions in all cryptosystems where applicable; however, further optimizations can be made by taking advantage of AVX2 or other wide vector technologies. The AES256 implementation takes advantage of the AES-NI instruction set, whereas all other cryptosystems tested do not use any additional vectorized instructions except AVX and SSE. RBC engines targeting purely CPU platforms were only considered for demonstrative purposes. The purpose of this experiment is to compare the relativistic performance between all five chosen cryptosystems. The ease of porting one cryptosystem to another all on the CPU influenced the scope of experiments. Future experimental evaluations exploring GPU focus will require more dedicated, specialized programming for each cryptosystem. The CPU used for the experiments was a 2\(\times\) Xeon Gold 6132 (Skylake) CPU with 28 total physical cores. Experiments were executed on a dedicated platform. All codes were written in C/C++, compiled using O3 optimization flag. The experiments were executed by randomly selecting a target thread and using the 256-bit permutation that is the middle of that given thread's workload. This guarantees that each run accurately reflects the average case where execution stops halfway through the 256 choose k search space, for any Hamming distance k. We decided to use this approach to reduce the need for a high number of iterations to reach a statistical central point. Thus, 10 iterations were performed for each cryptosystem, and the median response time was selected from the set of 10 time trials. The major key performance index (KPI) of the RBC search is key search throughput. Therefore, our performance evaluation uses the \"effective key throughput\" performance metric. Since the search increases exponentially with Hamming distance, the fraction of time spent initializing/dismantling our procedure will dominate the response time on small workloads (small Hamming distances). Consequently, to measure the effective key throughput, we use a sufficiently large Hamming distance in each algorithm such that we observe peak throughput, indicating that the initialization and dismantling procedures (freeing memory, deconstructing objects, etc.) constitute a negligible fraction of the total response time. For AES256, the minimum Hamming distance is 4, while for ECC Secp256r1, qTESLA-p-I, CRYSTALS-Dilithium 2, and LightSABER the minimum Hamming distance is 3.