Performance Considerations for PQC

What performance means for PQC

Performance evaluation should begin with the deployment path rather than with an algorithm name. Identify whether the operation is a KEM used for key establishment, a digital signature used for authentication, or a hybrid construction that combines components. Then measure the work and data that the protocol actually sends, stores, verifies, retries, and rejects. This matters because a cryptographic protocol incorporates one or more cryptographic schemes, while a KEM itself is only a three-function scheme: key generation, encapsulation, and decapsulation. TLS, for example, also includes authentication and record-layer processing.21

• Object dimensions: encapsulation and decapsulation keys, public verification and private signing keys, KEM ciphertexts, signatures, certificates, and transcript data.
• Compute dimensions: key generation, encapsulation, decapsulation, signing, and verification, including randomness generation and any required hashing or key derivation.
• System dimensions: peak and steady-state memory, bandwidth, packetization and fragmentation, handshake latency, energy, CPU utilization, concurrency, and queueing.
• Reliability dimensions: malformed inputs, decapsulation errors, signature rejection, retries, timeouts, and the operational effect of failures.

KEM performance: keys, ciphertexts, and operations

A KEM establishes a shared secret through key generation, encapsulation, and decapsulation. Key generation produces a public encapsulation key and a private decapsulation key. Encapsulation consumes the public key and private randomness and produces a shared secret plus an associated ciphertext. Decapsulation consumes the ciphertext and private key and produces the shared secret, or in some designs a distinguished error value. These inputs and outputs define the minimum KEM performance profile: measure each operation independently, then measure the messages and storage needed by the protocol.36

Key size is a first-order systems concern. The encapsulation key may be transmitted, cached, stored in certificates or configuration, or held in memory for many sessions. The decapsulation key is private and may be held by a service handling concurrent connections. Ciphertext size affects the response or handshake flight. A larger ciphertext can consume more packet space and can trigger fragmentation logic; a larger public key can affect certificate or key-distribution paths. The cited evidence states that PQC algorithms generally have larger keys and ciphertexts than traditional public-key algorithms, particularly affecting constrained devices with limited data rates.1

Parameter sets are not interchangeable performance labels. FIPS 203 describes ML-KEM as having parameter sets selected to trade security and efficiency, and identifies ML-KEM-512, ML-KEM-768, and ML-KEM-1024. A benchmark report should therefore name the exact parameter set, implementation, build options, processor, operating system, and measurement method. Reporting only “ML-KEM performance” hides a material source of variation.6

Failure behavior belongs in the KEM profile, not in a footnote. Some KEMs can experience decapsulation failures, returning an error or a session key that does not match the encapsulated key. ML-KEM’s specified decapsulation process includes implicit rejection when a re-encryption check does not match. Measure the cost and externally visible behavior of valid, malformed, and rejected ciphertexts, while ensuring that error handling does not create an exploitable distinction or an operational retry storm.756

Signature performance: generation, verification, and object size

Signature workloads have a different shape from KEM workloads. Measure signing and verification separately, because a deployment may sign relatively rarely but verify at high volume, or may have the reverse profile. Include key generation when keys are provisioned, rotated, or regenerated, and include certificate creation or validation where those activities are part of the deployment. The relevant objects are the public verification key, private signing key, signature, certificate, and signed transcript or message.348

Signature size affects more than the cryptographic library. It can enlarge certificates, authentication messages, logs, storage records, and protocol flights. The cited engineering guidance states that PQC algorithms generally have larger signatures than traditional public-key algorithms and that larger message sizes can increase handshake latency, energy consumption, and fragmentation requirements. Measure the actual wire representation, including encoding, certificate wrappers, hybrid components, and any duplicated information.1

Do not assume one signature algorithm is fastest for every role. The cited guidance reports that ML-DSA is generally known for relatively fast signature generation, while FN-DSA can provide more efficient signature verification, with the choice depending on whether generation or verification is more frequent. It also states that characteristics can differ by implementation and hardware platform. Those statements support workload-specific comparison, not a universal ranking.1

Randomness and side-channel requirements can change the practical profile. FIPS 204 requires fresh random input of at least the specified security strength for ML-DSA key generation. The cited guidance also warns that FN-DSA signing is highly susceptible to side-channel attacks unless constant-time 64-bit floating-point operations are used, making the requirement platform-dependent. A fair test must measure the approved or security-required implementation path, rather than an unsafe shortcut.41

Why primitive benchmarks do not predict protocol performance

A microbenchmark answers a narrow question such as how long one encapsulation or one verification takes in a warm process. A protocol answers a broader question: how many objects are generated, transmitted, parsed, copied, verified, stored, and rejected, and how those actions interact with round trips, packet limits, congestion, certificates, authentication, and application scheduling. RFC 9794 distinguishes an algorithm, a cryptographic scheme, and a cryptographic protocol; this distinction is central to performance analysis.215

Communication can dominate computation. The cited evidence reports that PQC algorithms generally have larger keys, ciphertexts, and signatures, and that larger messages can increase handshake latency, energy consumption, and fragmentation logic. Another cited passage notes that hybrid algorithms can range from hundreds of bytes to over one hundred kilobytes and that the tolerance for increased latency depends on the system and network. Consequently, an algorithm that looks acceptable in a CPU-only test may produce a poor user-visible result on a high-latency, low-rate, or fragmentation-prone path.15

Hybrid evaluation must include both components and the combination rules. In a hybrid KEM, component encapsulations and component decapsulations are performed and their session keys are combined through a key-derivation function. That means object sizes, primitive work, key storage, parsing, and failure handling can all differ from a single-component test. A hybrid protocol should also be tested for its actual flight structure and should not be credited with a “no extra round trip” result merely because the primitive benchmark has no network.

Protocol reuse and caching can also alter results. The cited ETSI evidence explains that, with a PQC KEM or hybrid KEM, a server ciphertext depends on the client public key, so caching behavior differs from a traditional example in which a server may cache a public key for a short period. It further warns that reusing the same random seed for ciphertexts to different client public keys can expose session keys. Performance optimizations must therefore be tested against the algorithm’s security and randomness requirements.

A workload-specific PQC test plan

Start by defining representative scenarios: new connection, resumed or long-lived connection where applicable, certificate or identity validation, concurrent handshakes, steady-state verification, key provisioning, rotation, and malformed-input handling. Record whether the scenario uses a KEM, a signature, or a hybrid scheme. For every result, record the parameter set, implementation and version, compiler or build mode, processor and accelerator configuration, operating system, security mitigations, randomness mode, message encoding, network model, and concurrency level.25

1. Measure object sizes before optimization: public and private keys, ciphertexts, signatures, certificates, transcript elements, and the complete protocol flight.
2. Measure each primitive operation separately: key generation, encapsulation, decapsulation, signing, and verification. Report distributions, not only a single average, when latency matters.
3. Run an end-to-end protocol test with realistic packet limits, loss, latency, bandwidth, connection churn, and certificate chains. Record handshake completion time, bytes sent and received, retransmissions, fragmentation, and timeout rates.
4. Measure resource impact: peak memory, long-lived key storage, temporary buffers, CPU utilization, queue depth, energy where relevant, and behavior at the target concurrency.
5. Inject invalid and adversarially malformed inputs. Record rejection cost, error classification, connection handling, retries, and whether failures remain safe and operationally bounded.
6. Compare parameter sets and hybrid combinations under the same conditions. Choose based on the required security and workload, not on an isolated fastest result.

Concurrency deserves explicit treatment even when a source does not provide a universal concurrency limit. A service can have acceptable single-request latency but exhaust memory or queue workers when many decapsulations, verifications, or handshakes arrive together. Measure active operations, per-connection temporary allocations, private-key access, synchronization, queueing, and tail latency. Treat hardware acceleration as an experimental variable rather than an assumed capability: compare the exact supported implementation path with and without acceleration, and verify that the security protections and constant-time requirements remain in force.341

Energy and constrained-device results require the same discipline. Larger messages can increase radio or link activity, handshake latency, energy consumption, and fragmentation logic. Measure energy per successful handshake and per rejected attempt where the device and workload make energy material. Include sleep and wake behavior, retransmissions, parsing, memory movement, and cryptographic computation; a CPU-only energy estimate is not an end-to-end device result.15

How to report results without misleading comparisons

A useful report separates facts from interpretation. State the exact source status and version used for normative algorithm behavior, then state the test environment and workload. Do not publish an unqualified claim such as “PQC is slower” or “algorithm X is fastest.” The cited evidence supports qualitative conclusions about larger objects and system effects, and it reports workload- and platform-dependent differences among signature algorithms; it does not supply one universal numeric result for all implementations or environments.1

• KEM report: parameter set; encapsulation-key and decapsulation-key sizes; ciphertext size; key-generation, encapsulation, and decapsulation latency; valid and invalid-input behavior; memory and concurrency.
• Signature report: parameter set; verification-key and signing-key sizes; signature size; key-generation, signing, and verification latency; randomness and side-channel implementation conditions; verification concurrency.
• Protocol report: complete message sizes; fragmentation; bandwidth; round trips; handshake latency distribution; certificate and transcript overhead; retries and failures; CPU, memory, and energy.
• Comparison statement: explain which workload favors which option and identify all conditions that limit generalization.

Planning implications

Performance work should be coordinated with algorithm selection, hybrid design, and migration planning. NIST identifies ML-KEM, ML-DSA, and SLH-DSA as the foundation expected for most deployments and states that they can be put into use now; the same evidence notes ongoing evaluation of additional algorithms. This makes repeatable measurement and crypto agility important: a deployment should be able to retest and replace algorithm components as standards, implementations, and workload requirements evolve.

For background, see the prerequisite topic on Algorithm Selection for PQC (kb-033), the related topic on Hybrid Cryptography (kb-031), and the adoption topics Challenges in PQC Adoption (kb-035) and Enterprise PQC Adoption (kb-036). These relationships are intended to connect performance testing with selection, migration, and operational planning rather than to replace workload-specific evidence.

Conclusion

PQC performance is an end-to-end engineering property. Measure KEMs and signatures according to their distinct operations, object sizes, security parameters, and protocol roles. Then test the complete workload across computation, memory, bandwidth, fragmentation, latency, energy, concurrency, and failure handling. Larger PQC objects and hybrid constructions can materially change network and device behavior, while implementation and platform differences can change operation-level results. The defensible conclusion is therefore not a universal ranking, but a reproducible, environment-bound measurement that preserves security requirements and exposes the costs users and operators will actually experience.1