PQC Energy Usage Metrics - crt26/PQC-LEO GitHub Wiki

The energy usage metrics collected by the project’s automated testing tools provide insight into the power consumption of PQC algorithms during both computational performance tests and TLS performance tests. These metrics are gathered using energy meters connected to the system, which measure the total energy consumed during the execution of cryptographic operations and TLS handshakes.

PQC-LEO provides automation scripts for collecting energy usage data for the following testing categories:

• PQC computational energy usage
• TLS handshake energy usage
• TLS operations energy usage

However, as the tools provided by the framework for gathering these metrics can be used outwith the automated testing suite, it is possible to gather energy usage metrics outwith the context of the provided testing scripts. This documentation will provide information on the above mentioned categories and provides a description of what values can be collected in general when using the energy usage collection tools outwith the context of the provided testing scripts.

As part of the evaluation process for each of the testing categories above, the automated testing scripts will gather a usage baseline for the system. This is done by sleeping for 60 seconds by default whilst the energy meter is polled during this testing window. The baseline measurement duration can be configured by passing --energy-baseline-duration=<TIME> when calling the testing machine script. The specified duration must be a positive whole number of seconds.

This data provides insight into the idle energy consumption of the device, allowing a meaningful comparison to be made between the energy consumed during testing and the baseline energy usage of the system. The data fields in this file will only include the raw usage metrics shown below in the energy usage metrics section of this document, and will not include any of the additional metadata fields. The filename of the baseline file for each testing category will be listed in the respective section of the documentation for that category.

The energy usage metrics that can be gathered by the current version of the Energy Meter API can be seen detailed in the table below. As support for additional energy meters is added, the range of available metrics that the API can gather may expand further. The Joules value is derived by the collector from mWh using the conversion $J = mWh \times 3.6$.

Metric	Description
Voltage (V)	Voltage reading sampled from the energy meter.
Current (A)	Current reading sampled from the energy meter.
Power (W)	Instantaneous power reading sampled from the energy meter.
mWh	Energy usage so far in milliwatt-hours during the test window.
mAh	Charge usage so far in milliamp-hours during the test window.
Joules	Derived energy usage in joules so far during the test window (mWh * 3.6).
Elapsed Time (ms)	Current elapsed measurement time in milliseconds for the current test sample stream.

In addition to the per-sample parsed CSV files, the parser also generates per-run condensed CSV files (*_condensed.csv). These condensed files group rows by test metadata and apply metric aggregation as follows:

Metric Group	Input Metrics	Columns Produced in Condensed Output
Poll metrics	Voltage (V), Current (A), Power (W)	Min, Max, Avg, Std. Dev
Total metrics	mWh, mAh, Joules, Elapsed Time (ms)	Total <Metric> (maximum observed value)
Group metadata	N/A	Total Record Count

If during the parsing process, the parser encounters a run where no energy usage data was collected, the blank line will be skipped and not included within the final record count.

The computational energy usage metrics measure the total energy consumed by the system during the execution of specific cryptographic operations for PQC algorithms. This is done by utilising the PQC KEM and digital signature implementations available from the Liboqs library. The energy usage collection tool runs the same cryptographic operations as the computational performance testing suite, but instead will perform energy measurement using connected energy meters. The collected energy usage data provides insight into the power efficiency of different PQC algorithms during their core operations.

Each cryptographic operation is run for a user defined number of iterations and the energy usage data is collected during this period. The rate at which the energy meter is polled for data during this period is also user defined.

In addition to the standard energy usage metrics, the computational energy usage result files will also include the following metadata fields to provide context for the energy usage data:

Metadata Field	Description
Algorithm Name	The specific PQC algorithm being tested.
Operation	The cryptographic operation being performed.

The baseline energy usage file for this testing category will be named: comp_energy_usage_baseline.csv

TLS handshake energy usage metrics measure the total energy consumed during the execution of TLS 1.3 handshakes using different PQC, Hybrid-PQC, and classical algorithm combinations. These measurements are obtained by executing the standard TLS handshake tests with energy monitoring enabled, allowing energy consumption data to be collected during the handshake operations. The resulting data provides insight into the power efficiency and practical implementation costs of different cryptographic algorithm combinations when deployed within real-world TLS 1.3 handshakes.

TLS handshake energy usage testing follows the same pattern as standard TLS handshake performance testing, with the exception that by default no handshake performance data is recorded. The user can choose to store the performance results when configuring the client machine. Testing is performed for both first use of a session ID and session ID reuse for each PQC/Hybrid-PQC signing-algorithm/KEM pairing and each classical signing-algorithm/key-exchange-group/ciphersuite combination. Energy usage data is collected during the handshakes for each scenario. For detailed information on the standard TLS handshake testing process, please refer to the TLS Handshake Performance Metrics section of the TLS performance metrics guide.

In addition to the standard energy usage metrics, the TLS handshake energy usage result files will also include the following metadata fields to provide context for the energy usage data.

For PQC and Hybrid-PQC results, the following metadata fields are included:

Metadata Field	Description
Signing Algorithm	The specific digital signature algorithm used in the handshake.
KEM Algorithm	The specific KEM algorithm used in the handshake.
Session ID Reuse (*)	Indicates whether session ID reuse was enabled for the handshake test.

For classical results, the following metadata fields are included:

Metadata Field	Description
Signing Algorithm	The specific digital signature algorithm used in the handshake.
Key Exchange Group	The classical key-exchange group used in the handshake.
Ciphersuite	The TLS 1.3 ciphersuite used for the classical handshake test.
Session ID Reuse (*)	Indicates whether session ID reuse was enabled for the handshake test.

The baseline energy usage file for this testing category will be named: tls_handshake_energy_usage_baseline.csv

TLS operations energy usage metrics evaluate the energy consumption of cryptographic operations for PQC, Hybrid-PQC, and classical algorithms within OpenSSL. The test performs individual operations using the OpenSSL command-line tools while energy monitoring is enabled. It measures key generation, encapsulation, and decapsulation for PQC/Hybrid-PQC KEMs; key generation, signing, and verification for PQC/Hybrid-PQC and classical signatures; and key generation and shared-secret derivation for classical key-exchange algorithms.

Because this test invokes OpenSSL operations directly rather than relying on the predefined openssl speed result categories, it can explicitly request RSA-PSS signing and verification. For its RSA results, the RSA_* categories use generic RSA keys and the RSA-PSS_* categories use RSA-PSS-restricted keys; both categories use PSS padding for the measured signing and verification operations.

Similar to computational energy usage testing, the TLS operations energy usage tests run each algorithm's respective cryptographic operations for a user-defined number of iterations while collecting energy usage data. The rate at which the energy meter is polled for data during this period is also user-defined.

In addition to the standard energy usage metrics, the TLS operations energy usage result files will also include the following metadata fields to provide context for the energy usage data:

Metadata Field	Description
Algorithm Name	The specific PQC, Hybrid-PQC, or classical algorithm being tested.
Operation	The cryptographic operation being performed.

The baseline energy usage file for this testing category will be named:

tls_operations_energy_usage_baseline.csv

Both the un-parsed and parsed energy usage results data will be stored on the collector machine which polls the energy meter during testing rather than the device which performs the cryptographic operations. When using the automated collector and testing scripts provided by the project, the following directory structure will be used for storing the energy usage metrics data. If the energy usage collection tools are used outwith the context of the provided testing scripts, the way result data is stored will depend on how the respective programmes were configured during setup and execution.

Energy Usage Metrics Data Storage:

Testing Category	State	Description	Location (relative to test_data/)
Computational Energy	Un-parsed	Raw text files containing energy usage data for PQC cryptographic operations.	up_results/energy_test_results/pqc_performance_energy_results/machine_x/
Computational Energy	Parsed	Processed per-run CSV result files, plus condensed per-run CSV summaries.	results/energy_test_results/pqc_performance_energy_results/machine_x/
TLS Handshake Energy	Un-parsed	Raw text files for each PQC/Hybrid SIG/KEM or classical signature/group/ciphersuite handshake test.	up_results/energy_test_results/tls_handshake_energy_results/machine_x/
TLS Handshake Energy	Parsed	Processed per-run CSV result files grouped into classic, pqc, and hybrid_pqc, plus condensed files.	results/energy_test_results/tls_handshake_energy_results/machine_x/{classic/pqc/hybrid_pqc}/
TLS Operations Energy	Un-parsed	Raw text files containing energy usage data for each algorithm and operation.	up_results/energy_test_results/tls_operations_energy_results/machine_x/
TLS Operations Energy	Parsed	Per-run PQC, Hybrid-PQC, and classical CSVs by algorithm type, plus condensed files.	results/energy_test_results/tls_operations_energy_results/machine_x/{pqc/hybrid/classic}/

Where machine_x is the Machine-ID number assigned to the results when executing the testing scripts. If no custom Machine-ID is assigned, the default ID of 1 will be set for the results.

TLS operations energy parsing produces pqc and hybrid_pqc KEM/signature result files and classic signature/key-exchange result files. These are stored in the pqc, hybrid, and classic sub-directories, respectively. The filename format is tls_operations_(algorithm-group)_(algorithm-type)_(run-number).csv, with a matching _condensed.csv summary for each file. The baseline CSV remains directly under the machine directory.