# Energy Consumption Framework and Analysis of Post-Quantum Key-Generation on Embedded Devices
## 4 Methodology  
The experiments were designed to record the empirical energy utilisation over a significant number of iterations, to establish a reliable baseline. Key generation for each algorithm was executed multiple times across 10,000, 100,000, and 500,000 rounds--from under an hour to over a day in total duration. Where the key generation times were considerably longer (for instance, with larger RSA key sizes), a lower iteration count was used, and the corresponding experiments were adjusted accordingly, balancing out the time on test for each algorithm.  
Furthermore, multiple NULL runs were performed in between key generation runs, involving identical numbers of loop iterations but triggering a 5 ms delay instead of the OpenSSL key generation operation. The 5 ms duration of the delay was not critical; rather, these runs served to capture the baseline energy consumption of the Raspberry Pi platform (including the fan) incorporating everything other than the key generation itself. This background energy usage (averaged over multiple NULL runs) was then subtracted from the results obtained, including the actual OpenSSL key generation processes.  
Software were developed to execute in the test environment, including cycling through the different key generation parameters, to trigger the start and stop of data capture from the energy meter and to provide feedback to the test operator on the status of the experiment. An example of live test runs and actual screen captures the tests can be reviewed in (Appendix A).  
Specific steps taken to ensure consistent measurement included running the fan on the Pi at 100% for all experiments, fixing the CPU clock to minimise the potential for dynamic frequency and voltage scaling influencing results, and pausing several seconds before starting the experiment to ensure the environment had settled, particularly in relation to the fan speed.  
\begin{table}
\begin{tabular}{l l l l} \hline
**NIST Sec Level** & **Protocol** & **Category** & **Equiv. Bit Size** \\ \hline Level 1 & RSA-1024 & Classic Technology & 80 \\ \hline Level 2 & EC secp160r1 & Elliptic Curve Cryptography & 80 \\  & RSA-1536 & Classic Technology & \(\sim\)96 \\ \hline  & EC secp224r1 & Elliptic Curve Cryptography & 112 \\  & RSA-2048 & Classic Technology & 112 \\ Level 3 & EC P-256 (secp256r1, FIPS 186-4) & Elliptic Curve Cryptography & 128 \\  & ML-DSA-44 & Post-quantum Technology & \(\sim\)128 \\  & ML-KEM-512 (Kyber-512, FIPS 203) & Post-quantum Technology & \(\sim\)128 \\ \hline  & RSA-3072 & Classic Technology & 128 \\ Level 4 & EC P-384 (secp384r1, FIPS 186-4) & Elliptic Curve Cryptography & 192 \\  & ML-DSA-65 & Post-quantum Technology & \(\sim\)192 \\  & ML-KEM-768 (Kyber-768, FIPS 203) & Post-quantum Technology & \(\sim\)192 \\ \hline  & RSA-4096 & Classic Technology & \(\sim\)140 \\ Level 5 & EC P-521 (secp521r1, FIPS 186-4) & Elliptic Curve Cryptography & 256 \\  & ML-DSA-87 & Post-quantum Technology & \(\sim\)256 \\  & ML-KEM-1024 (Kyber-1024, FIPS 203) & Post-quantum Technology & \(\sim\)256 \\ \hline \end{tabular}
\end{table}
Table 1: NIST security levels and equivalent symmetric key sizes for OpenSSL key generation protocols (based on NIST SP 800-57 Part 1 Rev. 5 (Table 2) [43] and the author’s categorisation).  
The test framework was carefully designed to provide a consistent environment for each run and to ensure that accurate, repeatable experimental results could be gathered. The principle that results gathering should not impact the device under test through viewing of its status was followed to develop the solution--minimising the triggering of the 'observer effect', such as through reporting using a separate collection machine rather than the device under test (DUT).