A Systems-Level Performance Study of Post-Quantum TLS with ML-KEM and ML-DSA in Modern OpenSSL

Abstract

Large-scale quantum computers threaten the classical public-key foundations of Transport Layer Security (TLS), motivating deployment of standardized post-quantum cryptography (PQC). This study evaluates post-quantum TLS 1.3 as a systems-level deployment problem in OpenSSL 3.4.1 with the Open Quantum Safe provider and in OpenSSL 3.5.0 with native PQC support. We combine cryptographic microbenchmarks, TLS 1.3 connection timing, end-to-end HTTP time to first byte (TTFB), controlled network impairment, packetization analysis, and concurrency tests on two x86-64 systems, and release the measurement archive with the analysis scripts. For hybrid X25519MLKEM768, the median TTFB overhead relative to classical TLS was 6.5–7.5% with OpenSSL 3.4.1 and 1.2–1.3% with OpenSSL 3.5.0. These cross-release comparisons describe complete software configurations. In authentication-matched runs, replacing RSA-PSS with ML-DSA-65 changed median TTFB by −3.0 to +0.1 ms. The full-PQC configuration enlarged the server handshake flight from 1.3 kB to 10.1 kB, mainly through ML-DSA-65 authentication, and increased server-to-client payload segments from 4–5 to 11–13. At a round-trip time of 50 ms, 1% packet loss increased p99 TTFB 6–8-fold in all configurations. Most of this tail consisted of requests delayed by about 1 s, whose frequency matched the probability of losing a TCP connection-establishment segment and was similar for all configurations. Under concurrent load, OpenSSL 3.5.0 completed 46–58% more requests per second.

1. Introduction

Transport Layer Security (TLS) is the dominant mechanism for securing application traffic over untrusted networks, and its security rests on public-key primitives used during the handshake for key establishment and authentication. Classical deployments rely heavily on RSA- and elliptic-curve–based assumptions (e.g., integer factorization and discrete logarithms). If a cryptographically relevant quantum computer becomes available, these assumptions no longer hold. The quantum algorithms introduced by Peter W. Shor [1] enable polynomial-time factoring and discrete logarithms, which would undermine RSA and elliptic-curve Diffie–Hellman key exchange at scale.

Even before such machines exist, the practical threat model is “harvest now, decrypt later”, i.e., adversaries can store today’s intercepted ciphertext and decrypt it once quantum capabilities mature. This is especially acute for long-lived confidentiality requirements (e.g., regulated records, industrial telemetry, or proprietary designs), where the value of data persists longer than the expected migration window for cryptographic infrastructure.

To accelerate the transition from classical to quantum-resistant cryptography [2], the National Institute of Standards and Technology (NIST) finalized the first set of post-quantum cryptography (PQC) Federal Information Processing Standards (FIPS) in August 2024: FIPS 203 [3], defining the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM), FIPS 204 [4], defining the Module-Lattice-Based Digital Signature Algorithm (ML-DSA), and FIPS 205 [5], defining the Stateless Hash-Based Digital Signature Algorithm (SLH-DSA).

In parallel, protocol designers and operators have largely converged on hybrid migration strategies: combining a classical key exchange (for backward assurance and compatibility) with a post-quantum KEM (for quantum resistance). This defense-in-depth approach aims to retain security if either the classical or post-quantum component is later found weaker than expected, while enabling staged deployment and risk management.

It is important to note that PQC transition is not only a cryptographic decision. It is a systems decision. Post-quantum primitives often increase computation cost, message sizes, or both, with direct consequences for latency, bandwidth, and operational reliability. For TLS specifically, larger handshakes can increase fragmentation, retransmissions, and middlebox sensitivity. These are effects that may remain invisible in idealized, low-loss laboratory tests.

Related works already show that network characteristics strongly shape handshake behavior. For example, in constrained and lossy Internet of Things (IoT) environments, handshake reliability mechanisms and message sizing can dominate observed performance, and a small maximum transmission unit (MTU) or poor link quality can amplify retransmission costs [6]. More broadly, recent journal frameworks for evaluating post-quantum TLS [7] emphasize that realistic assessment must incorporate not only microbenchmarks of primitives but also protocol-level measurements under controlled network impairment and application-level workloads.

Additionally, comparative work at the web stack level has begun to quantify how hybrid and post-quantum primitives behave across different transports (TLS/TCP vs QUIC/UDP) [8], highlighting that handshake overhead interacts with loss and that protocol choice can materially affect the penalty of post-quantum adoption. Finally, other works [9] exploring quantum-resistant variants of TLS (sometimes combining PQC with quantum key distribution) underscore that quantum resistance is achievable in practice, but the performance/complexity trade space depends strongly on the chosen mechanism, e.g., PQC-only vs PQC and quantum key distribution (QKD) hybrids.

An important deployment question is how standardized post-quantum TLS performs in mainstream software stacks and which operational factors, such as packet loss, MTU, and concurrent demand, shape its measured performance. The evolving OpenSSL ecosystem enables comparisons between releases using external PQC support and those incorporating standardized algorithms natively.

Despite advances in post-quantum TLS benchmarking, deployment-oriented evidence remains important for understanding how standardized cryptographic configurations perform across evolving mainstream TLS implementations and different operating conditions. In particular, network impairment, packetization, and concurrent execution introduce performance considerations that cannot be captured through cryptographic microbenchmarks alone. This study addresses these complementary dimensions through a coordinated evaluation of cryptographic operations, TLS and HTTP performance, controlled network impairment, TCP packetization, and concurrent workloads across the evaluated OpenSSL configurations.

The contribution of this study lies in a coordinated, systems-level evaluation of post-quantum TLS deployment rather than an assessment limited to cryptographic primitives. By examining OpenSSL performance across cryptographic operations, TLS handshakes, HTTP response timing, network impairment, packetization, and concurrent workloads, we characterize the observed behavior of classical, hybrid, and full-PQC configurations. This approach provides complementary evidence on cross-version performance differences and deployment-relevant transport effects. Specifically, this work makes the following contributions:

• Version-aware PQC deployment analysis. We characterize the observed performance of OpenSSL 3.4.1 configured with oqs-provider and OpenSSL 3.5.0 with native PQC support across representative TLS configurations. Cross-version differences are reported as properties of complete software configurations.
• Multi-layer performance characterization. We provide complementary measurements of cryptographic primitives, TLS 1.3 handshake latency, and end-to-end HTTP time to first byte (TTFB), including authentication- and key-establishment-matched HTTP comparisons. Because the handshake and HTTP measurements use partially different cryptographic configurations and timing boundaries, they are interpreted as complementary evidence rather than as an additive decomposition of end-to-end latency.
• Network-induced tail-risk analysis. We quantify how round-trip time (RTT), packet loss, and MTU influence p95/p99 latency and failure behavior for classical, hybrid, and full-PQC deployments, and decompose the loss-induced tail into delay classes that can be related to TCP recovery events.
• Packetization and transport sensitivity analysis. We characterize server-to-client TCP segmentation and the byte contribution of each TLS 1.3 handshake message for five key-establishment and authentication combinations, and relate this larger exposure to the loss-induced delays observed under impairment.
• Capacity and deployment implications. We characterize throughput and tail latency under concurrent load and state the deployment implications that these controlled measurements support.
• Open measurement archive. We release all 2424 measurement records with a checksum manifest, the benchmark source code, and analysis scripts that regenerate every table and figure, together with documentation of measurement definitions, provenance, and limitations.

The remainder of this article is structured as follows. Section 2 reviews related work on PQC protocol integration and PQC with TLS benchmarking. Section 3 details our experimental methodology and configurations. Section 4 presents and discusses performance results across microbenchmarks, TLS/HTTP tests, impairment sweeps, and concurrency. Section 5 concludes the article by summarizing the main findings, limitations, and directions for future research.

2. Related Work

Post-quantum cryptography has rapidly moved from algorithmic standardization toward systems integration. Foundational work established the vulnerability of classical public-key cryptography to quantum algorithms and the broader engineering challenges of replacing RSA- and elliptic-curve–based mechanisms [10], while more recent studies have emphasized that PQC migration is a multi-layer process involving protocols, public key infrastructure (PKI), software stacks, and operational practices [11]. The publication of the first NIST PQC standards, including ML-KEM, ML-DSA, and SLH-DSA, has further shifted the research focus from candidate evaluation toward reproducible implementation and deployment studies [2,3,4,5].

A recurring theme in the PQC literature is that deployment performance depends not only on the cryptographic construction itself but also on how the primitive is integrated into the protocol stack. Lattice-based schemes such as ML-KEM and ML-DSA are computationally efficient on modern CPUs, but their larger keys, ciphertexts, and signatures can increase handshake size and amplify transport-level effects. Consequently, user-perceived performance emerges from the interaction between primitive cost, TLS implementation, CPU characteristics, and network conditions rather than from cryptographic latency alone [12]. This distinction is particularly important for TLS, where even small changes in handshake processing or message size can propagate into application-level latency and server capacity.

Within TLS, hybrid key establishment has emerged as the main near-term migration strategy, combining a classical key agreement with a post-quantum KEM so that confidentiality is preserved unless both components are compromised. This approach reduces transition risk and supports staged deployment, but it also increases handshake complexity because classical and post-quantum key material must coexist within the same exchange. As a result, hybrid TLS introduces a systems-level trade-off between cryptographic resilience and additional computation, message size, and protocol processing. Several migration-oriented proposals have explored ways to reduce ecosystem disruption while retaining hybrid protection [13], but their practical cost ultimately depends on how the hybrid mechanism is implemented within the TLS stack and how the resulting handshake behaves under realistic network conditions.

Related work has also explored quantum-resistant TLS variants that combine PQC with QKD, showing that stronger key-establishment mechanisms can be integrated into TLS-like workflows, although with deployment assumptions and infrastructure requirements that differ substantially from mainstream PQC-only migration [9].

Recent empirical work has moved beyond primitive-level benchmarks toward reproducible, protocol-level evaluation. Montenegro et al. [7] present a post-quantum TLS performance framework based on OpenSSL and OQS integration, linking KEM and signature microbenchmarks with classical, hybrid, and post-quantum TLS configurations under controlled conditions. Their study demonstrates the importance of evaluating both computational and communication overhead rather than inferring deployment cost from cryptographic operations alone.

In subsequent work, Montenegro et al. [8] extend this perspective by comparing post-quantum handshakes across TLS and QUIC, showing that transport choice and network conditions materially affect the observed cost of PQC adoption. These studies provide an important methodological foundation for deployment-oriented benchmarking.

Taken together, previous studies establish that post-quantum TLS performance cannot be inferred from cryptographic primitive timings alone. Computational cost, handshake size, transport behavior, and network conditions interact, and their relative importance depends on both the protocol configuration and the execution environment. Existing evaluation frameworks have therefore moved progressively toward end-to-end measurements and controlled network impairment. For context, Montenegro et al. [7] benchmark classical, hybrid, and post-quantum TLS combinations using an OpenSSL/OQS-based framework with primitive-level and protocol-level evaluation under controlled network conditions. Their subsequent study [8] extends the comparison to TLS/TCP and QUIC/UDP handshakes, using a containerized testbed on an Intel Xeon Silver 4214 server and evaluating different cryptographic security levels and network impairments. The present work instead compares OpenSSL 3.4.1 and 3.5.0 deployments on two different x86-64 systems, with explicitly identified RSA-PSS and ML-DSA-65 authentication configurations, HTTP first-byte timing, TCP packetization, and concurrent client–server requests. Because the cryptographic configurations, hardware platforms, protocol scope, and timing boundaries are not matched across these studies, their numerical performance differences should not be interpreted as directly interchangeable.

An important practical question is how the transition from provider-enabled to native PQC support in mainstream TLS libraries relates to end-to-end performance. This study compares the observed behavior of OpenSSL 3.4.1 configured with oqs-provider and OpenSSL 3.5.0 with native support for standardized PQC. We evaluate cryptographic operations, TLS handshakes, HTTP response timing, controlled network impairment, and concurrent workloads, complemented by a separate analysis of TCP packetization under OpenSSL 3.5.0. Together, these measurements provide a deployment-oriented characterization of the evaluated configurations.

3. Methodology

3.1. Experimental Platforms and Software Stack

All benchmarks were executed on two Linux x86_64 systems to capture both developer-class and server-class behavior: (1) a laptop with an Intel Core i5-10300H CPU @ 2.50 GHz and (2) a lab server with an Intel Core Ultra 9 285 CPU. Both systems ran kernel 6.14.0-37-generic. The TLS stacks under test were OpenSSL 3.4.1 and OpenSSL 3.5.0, with OpenSSL 3.5.0 providing native support for ML-KEM, ML-DSA, and SLH-DSA [14]. The provider module used where applicable was oqs-provider 0.11.0-rc1 [15]. The archived records identify the OpenSSL and oqs-provider versions; the liboqs version, source commits, and build options of the original installations were not recorded.

To isolate cryptographic and TLS stack overhead from uncontrolled wide-area effects, client and server processes ran on the same host and communicated over loopback in the baseline experiments. This local baseline is used for microbenchmarks, handshake timing, and end-to-end HTTPS timing.

3.2. TLS Stacks and PQC Integration Modes

The experimental comparison considers two OpenSSL releases with different mechanisms for making standardized post-quantum algorithms available. OpenSSL 3.4.1 was configured with oqs-provider, whereas OpenSSL 3.5.0 includes native support for ML-KEM and the standardized X25519MLKEM768 hybrid group. The cross-version measurements characterize the observed performance of these software configurations as deployed in the benchmark environment. Because the release and the integration mechanism change together, these measurements cannot separate their effects (Section 4.1).

Two OpenSSL 3.5.0 HTTP benchmark result sets were archived for X25519MLKEM768, originally labelled as provider-based and native, respectively. However, a loaded provider and a requested TLS group do not establish which implementation processed a connection. In particular, oqs-provider disables its implementation of X25519MLKEM768 when the same group is available natively in OpenSSL 3.5.0. The historical records do not independently establish distinct provider execution paths for these runs. Accordingly, they are retained as separately recorded measurements of the same nominal TLS configuration, not as an isolated comparison of native and provider-mediated cryptographic execution. A post hoc functional check in a separate environment (OpenSSL 3.4.1 and 3.5.0, oqs-provider 0.11.0-rc1, liboqs 0.15.0) showed that, with oqs-provider loaded, OpenSSL 3.5.0 registers X25519MLKEM768 only in its default provider, whereas OpenSSL 3.4.1 obtains it from oqs-provider; the commands and observations are documented in the data repository. If the archived runs used the recorded provider version, both OpenSSL 3.5.0 runs used the native implementation.

3.3. Evaluated Cryptographic Configurations

The experimental configurations combine different key-establishment and certificate-authentication mechanisms. Table 1 summarizes the combinations used across the benchmark families and distinguishes the controlled comparisons from the broader deployment scenarios.

Table 1. Cryptographic configurations evaluated across the benchmark families.

Benchmark Family	Key Establishment	Certificate Authentication
Classical: HTTP and network impairment (both systems and releases); concurrency (laptop); packetization (OpenSSL 3.5.0)	X25519	RSA-PSS (RSA-2048)
Hybrid: HTTP and network impairment (both systems and releases); concurrency (laptop); packetization (OpenSSL 3.5.0)	X25519MLKEM768	RSA-PSS (RSA-2048)
Key-establishment control: baseline HTTP (both systems and releases); packetization (OpenSSL 3.5.0)	ML-KEM-768	RSA-PSS (RSA-2048)
Full PQC: HTTP and network impairment (both systems and releases); concurrency (laptop); packetization (OpenSSL 3.5.0)	ML-KEM-768	ML-DSA-65
KEM-focused TLS connection timing	KEM under test, including X25519MLKEM768	ML-DSA-65
Authentication control: packetization only (OpenSSL 3.5.0)	X25519	ML-DSA-65

The archive contains three HTTP configurations that form a partial factorial design: X25519 with RSA-PSS (classical), ML-KEM-768 with RSA-PSS, and ML-KEM-768 with ML-DSA-65 (full PQC). Comparing the first two isolates the change in key establishment, and comparing the last two isolates the change in authentication (Section 4.2). The hybrid configuration, X25519MLKEM768, also uses RSA-PSS. The fourth combination, X25519 with ML-DSA-65, was recorded only in the packetization captures, which cover all five combinations in Table 1. The KEM-focused handshake measurements use ML-DSA-65 authentication. These HTTP measurements include process initialization, TLS processing, and application-level overhead, so they do not isolate cryptographic operation costs.

All servers used a single self-signed leaf certificate generated for each run, either RSA-2048 with RSA-PSS signatures (749-byte DER certificate) or ML-DSA-65 (5478 bytes), without intermediate certificates. The client did not enforce certificate validation, all connections negotiated TLS_AES_256_GCM_SHA384, and session resumption was not used except in the session-reuse runs reported in Section 4.2. The results are therefore interpreted as measurements of the evaluated TLS configurations rather than as estimates of signature-operation costs.

3.4. Benchmark Categories and Workloads

The benchmark suite evaluates post-quantum TLS performance at complementary experimental layers. Cryptographic microbenchmarks characterize primitive-level computation, TLS handshake measurements capture protocol-level behavior, and HTTP benchmarks assess end-to-end response timing. Controlled network impairment experiments quantify sensitivity to RTT, packet loss, and MTU, while concurrency tests characterize the combined client–server workload under increasing parallel demand. These measurements provide complementary perspectives on deployment performance but do not constitute an additive decomposition of end-to-end latency or isolate individual software components.

3.4.1. Cryptographic Microbenchmarks

Low-level cryptographic performance was measured using openssl speed to isolate primitive-level computation costs from TLS processing and network effects. For the cross-layer analysis reported in this study, the microbenchmark evaluation focuses on the X25519 with ML-KEM-768 configuration used in the hybrid TLS experiments. Median key-generation, encapsulation, and decapsulation latencies were recorded under OpenSSL 3.4.1 and OpenSSL 3.5.0.

Each datapoint was repeated 10 times. These measurements are used to interpret the computational component of the higher-layer TLS and HTTP results rather than as direct predictors of end-to-end performance.

3.4.2. TLS 1.3 Connection Timing

TLS 1.3 connection establishment was evaluated using the OpenSSL s_server and s_client command-line tools. Each measurement recorded the elapsed wall-clock time from immediately before invoking a new s_client process until the command completed. We refer to this quantity as the s_client connection time. Consequently, the reported timings include client process execution, TCP connection establishment, TLS negotiation, and associated processing overhead, rather than isolated cryptographic or TLS handshake execution time. No application-layer HTTP request was included in these tests.

For the X25519MLKEM768 comparison reported in Section 4.2, the server used a self-signed ML-DSA-65 certificate. The benchmark did not enforce successful certificate-chain validation, so connection success should not be interpreted as verified certificate trust. Ten connection attempts were recorded per configuration, with median elapsed times and success/failure counts reported. These measurements complement the cryptographic and HTTP benchmarks but do not provide an additive decomposition of end-to-end latency.

3.4.3. End-to-End HTTPS Benchmarks (HTTP/1.1)

End-to-end HTTPS performance was evaluated using TTFB and total response time. For the OpenSSL-based workload, TTFB was operationally defined as the elapsed time measured with Python’s time.perf_counter() (benchmark suite pqc-bench 0.1.2, which requires Python 3.11 or later) from immediately before launching a new openssl s_client subprocess to the first byte received from its standard output. Each observation established a fresh TLS 1.3 connection and sent a minimal HTTP/1.1 GET request with Connection: close. Total response time was measured until the response stream was fully consumed and the client process was handled. Consequently, the reported TTFB includes subprocess creation and initialization, client-side scheduling, TCP connection establishment, TLS negotiation, and initial HTTP response processing. These components were not timed separately, and the resulting measurements should not be interpreted as isolated TLS handshake or cryptographic execution times.

The server used openssl s_server with the -www option, which generates an HTTP response containing connection-related information rather than a fixed, byte-identical static payload. The benchmark therefore characterizes the end-to-end behavior of this specific OpenSSL CLI-based workload. Each measured request used a new TLS connection without session reuse, except in the session-reuse runs (-sess_out/-sess_in) reported in Section 4.2, for which per-request resumption was not recorded. The concurrency experiments preserved this request-per-connection model while executing multiple client processes in parallel.

Separate phase-level timestamps, a persistent-client control, and a fixed-response workload were not recorded in the original experiments. This limits the extent to which the observed cross-version latency differences can be attributed to individual TLS-stack components.

3.5. Network Impairment Sweeps (tc netem)

Controlled network impairment experiments were used to quantify the sensitivity of post-quantum TLS to transport conditions that are not observable in ideal loopback measurements. The purpose of these experiments is not to reproduce the full statistical complexity of Internet paths, but to isolate the effect of three operational variables that directly affect TLS handshake behavior: MTU, RTT, and packet loss.

HTTP benchmarks were executed inside isolated Linux network namespaces connected through a veth pair, with impairments applied using tc netem. Each profile varied MTU over {1500, 1400, 1280} bytes, RTT over {0, 20, 50, 100} ms, and packet loss over {0, 0.1, 0.5, 1, 2}%. The sweep was performed for three representative deployment configurations: classical TLS, hybrid X25519MLKEM768, and full PQC using ML-KEM-768 with ML-DSA-65.

For each condition, 100 warm-up requests were discarded before collecting 1000 measured requests with a 5 s per-request timeout. A request was classified as failed when the timeout was exceeded while waiting for the first byte or completing the response. A netem qdisc on the egress of both veth interfaces applied half of the target RTT and independent random loss with the configured probability, so each packet crossed one lossy hop in each direction; no loss correlation, reordering, or rate limit was configured, and the default netem queue limit applied. Generic receive offload, generic segmentation offload, and TCP segmentation offload were disabled on the veth interfaces on a best-effort basis, so that packet segmentation reflected MTU boundaries rather than host-side offload behavior.

TCP packetization was examined separately, without impairment, from per-connection summaries of packet captures taken on the client-side veth interface under OpenSSL 3.5.0. Each capture comprised five s_client connections that completed the TLS 1.3 handshake, received two NewSessionTicket messages, and closed with a close_notify alert; no HTTP request was sent. For each connection and direction, the summaries record the payload-carrying TCP segments and the sequence and lengths of TLS records, which allows the server handshake flight (ServerHello to server Finished) to be identified. The binary captures and retransmission counts were not retained. A second capture session, recorded with the same OpenSSL 3.5.0 binary, produced identical segment counts and record sequences.

3.6. Capacity and Concurrency Benchmarking

Concurrency experiments characterized the performance of the co-located openssl client–server workload under increasing parallel demand. Tests were conducted on the laptop platform using classical, hybrid, and full-PQC configurations under OpenSSL 3.4.1 and 3.5.0. The Python benchmark employed a ThreadPoolExecutor with maximum worker counts of c ∈ {1, 10, 50, 100, 200}. Each request launched a new openssl s_client subprocess, established a fresh TLS 1.3 connection, and issued a single HTTP/1.1 GET request to a local openssl s_server -www endpoint. Accordingly, c represents the maximum number of concurrent client worker tasks rather than an independently measured number of established TLS connections.

For each condition, 100 sequential warm-up requests preceded 1000 measured requests, with a 5 s per-request timeout. Throughput, expressed as completed requests per second (RPS), was calculated by dividing the number of successful measured requests by the wall-clock duration of the measured batch, including task scheduling and worker-queue waiting. In contrast, individual TTFB measurements began immediately before launching the client subprocess within a worker and therefore included process initialization but excluded time spent waiting in the executor queue. The recorded metrics were RPS, p99 TTFB for successful requests, and failure rate.

Because the client and server shared the same host and CPU resources, these experiments measure the performance of the combined client–server workload rather than isolated TLS server capacity. The server endpoint was one OpenSSL s_server -www process; its internal connection scheduling, TCP accept backlog, and resource utilization were not measured separately. Each condition represents one recorded benchmark run; the results are interpreted descriptively and do not establish steady-state performance or production deployment capacity.

3.7. Statistical Treatment

All benchmark families follow a common descriptive statistical approach. Warm-up observations are discarded before analysis, and the median is used as the primary latency metric because it is less sensitive to occasional scheduling and system-level outliers than the arithmetic mean. For HTTP, network-impairment, and concurrency experiments, p95 and p99 are additionally reported to characterize tail behavior relevant to operational performance.

Cryptographic microbenchmarks contain 10 repetitions per algorithm and condition. Given this limited sample size, these measurements are interpreted descriptively and are used primarily to identify performance trends and to support the interpretation of higher-layer results rather than for inferential statistical testing.

The baseline HTTP experiments (Section 4.1 and Section 4.2) comprised 20 measured requests per run, following two discarded warm-up requests. The network-impairment and concurrency experiments comprised 1000 measured requests per condition, following 100 warm-up requests, with a 5 s timeout. Latency statistics, including p95 and p99, were computed from successful requests only, using linear interpolation between order statistics; unsuccessful requests are reported separately as failures. Each experimental condition corresponds to one recorded benchmark run, so between-run variability cannot be estimated for most conditions. To quantify within-run sampling uncertainty, we report 95% percentile-bootstrap confidence intervals (10,000 resamples) for medians and differences of medians [16], and distribution-free order-statistic confidence intervals for p99 [17]. These intervals do not include run-to-run variation, and no claim of statistical equivalence is made. Where the archive contains repeated records of the same nominal condition (47 network-impairment profiles), they are used to illustrate between-run variability (Section 4.3).

To relate tail latency to transport events, each successful request of a network-impairment profile was assigned to a delay class according to its excess over the profile median TTFB: 100–900 ms, 900–1600 ms (approximately 1 s), or more than 1600 ms. The 900 ms boundary lies in an empty region of the pooled excess-delay distribution. Class frequencies were compared between TLS configurations over matched profiles (same host, release, MTU, RTT, and loss rate), with 95% confidence intervals from a cluster bootstrap over the 48 matched profiles per loss rate.

3.8. Reproducibility Controls and Artifacts

All experiments were executed on otherwise idle systems, and CPU frequency scaling was disabled by using the performance governor to reduce run-to-run variability. The hardware, operating-system, OpenSSL, and oqs-provider versions used in each platform are reported explicitly in Section 3.1.

Benchmark outputs were preserved as structured JavaScript Object Notation (JSON) files organized by experimental platform, OpenSSL version, and benchmark category. The archived records include individual request-level measurements for the HTTP, network-impairment, and concurrency experiments, together with cryptographic timing data, TLS handshake summaries, and connection-level packetization records. The public repository (release v1.0.0; see the Data Availability Statement) contains these records unchanged with a SHA-256 manifest, the benchmark source code (the version recorded in every result file), measurement definitions derived from that code, and scripts that regenerate every table and figure in this article, including the complete impairment grid with p50, p95, p99, confidence intervals, and success and failure counts (Supplementary Tables S1–S3 in the repository [18]). Verifying implementation-specific cryptographic dispatch for the historical runs would require runtime evidence that was not recorded. CPU pinning was not enforced as a common experimental control.

4. Results

4.1. OpenSSL Migration and PQC Integration Effects

The migration from OpenSSL 3.4.1 to OpenSSL 3.5.0 produced a substantial reduction in end-to-end latency across the evaluated TLS configurations (see Table 2). For the hybrid X25519MLKEM768 configuration, the median HTTP TTFB overhead relative to the classical baseline decreased from 6.5% to 1.2% on the laptop and from 7.5% to 1.3% on the lab server. Similar improvements were observed for the classical and full-PQC paths, indicating that the performance gain was not limited to a single post-quantum primitive or configuration. The within-run 95% confidence intervals of these overheads exclude zero in three of the four cases; on the lab server under OpenSSL 3.5.0, the interval extends from −3.6% to +7.5%, so the hybrid overhead there cannot be distinguished from zero. Because each median is based on only 20 measured requests from a single run, differences of a few percent between baseline configurations should be interpreted with caution.

Table 2. End-to-end HTTP TTFB across OpenSSL versions and deployment configurations. Hybrid = X25519MLKEM768 key establishment with RSA-PSS authentication. Full PQC = ML-KEM-768 key establishment with ML-DSA-65 authentication. Values are median TTFB measurements. Cross-version differences reflect complete software configurations (Section 4.1). Each median is based on 20 measured requests from one run; overheads are computed from unrounded medians. Brackets give the within-run 95% bootstrap confidence interval of the hybrid overhead (20 requests per run; Section 3.7).

System	OpenSSL Path	Classical TTFB (ms)	Hybrid TTFB (ms)	Hybrid Overhead vs. Classical	Full-PQC TTFB (ms)
Laptop	3.4.1 with oqs-provider	51.5	54.8	+6.5% [+4.1, +17.6]	34.0
Laptop	3.5.0 native	22.1	22.4	+1.2% [+0.5, +1.7]	22.7
Lab server	3.4.1 with oqs-provider	20.4	21.9	+7.5% [+6.2, +9.0]	20.7
Lab server	3.5.0 native	16.3	16.5	+1.3% [−3.6, +7.5]	14.3

These cross-version results represent the practical effect of migrating the TLS stack from OpenSSL 3.4.1 with oqs-provider to OpenSSL 3.5.0 with native PQC support. However, they should not be interpreted as evidence that native integration alone accounts for the observed improvement, because the OpenSSL version changes simultaneously. The classical baseline likewise showed lower median TTFB, decreasing from 51.5 to 22.1 ms on the laptop and from 20.4 to 16.3 ms on the lab server. This confirms that the observed cross-version improvement was not limited to post-quantum TLS configurations.

Two full-PQC HTTP median TTFB results were lower than their classical counterparts: 34.0 versus 51.5 ms on the laptop under OpenSSL 3.4.1 and 14.3 versus 16.3 ms on the lab server under OpenSSL 3.5.0 (Table 2). These end-to-end values do not demonstrate that the full-PQC primitives are intrinsically faster. The key-establishment control in Section 4.2 reproduces both orderings with ML-KEM-768 and RSA-PSS authentication (37.0 and 14.2 ms), so they are associated with the key-establishment configuration rather than with ML-DSA-65. Their underlying cause cannot be identified from the archived records.

Table 3 reports two archived OpenSSL 3.5.0 HTTP benchmark runs requesting X25519MLKEM768, identified by their original result files. Their median TTFB values differ by 0.13% on the laptop and 0.91% on the lab server, with within-run 95% confidence intervals of −0.58% to +0.61% and −3.85% to +4.83%, respectively. The differences are therefore within the sampling uncertainty of a single 20-request run. Because oqs-provider does not register X25519MLKEM768 under OpenSSL 3.5.0 (Section 3.2), both runs most likely used the native implementation, and Table 3 indicates run-to-run variation of one configuration rather than provider overhead. This variation is of the same order as the 1.2–1.3% hybrid overhead under OpenSSL 3.5.0 in Table 2.

Table 3. Two separately recorded X25519MLKEM768 HTTP benchmark runs under OpenSSL 3.5.0. Run A corresponds to the archived hybrid-labelled file (18-http-openssl-hybrid.json), and Run B to the separately native-labelled file (37-http-native-x25519mlkem768.json). Each run contains 20 successful measured requests. The original labels do not establish execution by distinct cryptographic implementations. Positive differences indicate higher median TTFB in Run B relative to Run A. Brackets give within-run 95% bootstrap confidence intervals. Differences are computed from unrounded medians.

System	Run A TTFB (ms)	Run B TTFB (ms)	Difference (ms)	Relative Difference
Laptop	22.355	22.384	+0.029 [−0.130, +0.137]	+0.13% [−0.58, +0.61]
Lab server	16.527	16.677	+0.150 [−0.655, +0.779]	+0.91% [−3.85, +4.83]

The OpenSSL 3.5.0 hybrid results reported in Table 2 correspond to Run A in Table 3, with unrounded median TTFB values of 22.354988 ms on the laptop and 16.526602 ms on the lab server. The corresponding Run B values of 22.384 and 16.677 ms originate from a separate benchmark execution. Therefore, the differences reflect separately recorded runs of the same nominal TLS configuration rather than rounding discrepancies or verified differences between cryptographic implementations.

4.2. From Cryptographic Operations to End-to-End TLS Performance

The layered measurements reveal that primitive-level performance does not translate directly into protocol- or application-level behavior as shown in Table 4. On the laptop, the X25519 with ML-KEM-768 microbenchmark showed no uniform improvement between OpenSSL 3.4.1 and 3.5.0. Median encapsulation latency increased slightly, from 79.7 to 84.7 μs, while decapsulation decreased from 81.3 to 66.9 μs. Key-generation latency also changed from 48.9 to 73.3 μs. These mixed primitive-level trends contrast with the much larger improvements observed at higher layers.

Table 4. Cross-layer comparison of X25519MLKEM768 performance on the laptop across OpenSSL versions. Primitive values are medians of 10 openssl speed repetitions. Connection time is the median elapsed time from launching s_client until the process exits after the TLS 1.3 handshake (ML-DSA-65 authentication, 10 connections). HTTP TTFB is the median time from launching s_client until the first response byte (RSA-PSS authentication; Run A in Table 3, 20 requests). The rows are complementary measurements rather than an additive latency decomposition. Relative changes are computed from unrounded medians.

Measurement Layer	Metric/Configuration	OpenSSL 3.4.1	OpenSSL 3.5.0	Relative Change
Cryptographic primitive	Key generation	48.9 µs	73.3 µs	+49.8%
Cryptographic primitive	Encapsulation	79.7 µs	84.7 µs	+6.3%
Cryptographic primitive	Decapsulation	81.3 µs	66.9 µs	−17.7%
s_client connection time (launch to exit)	X25519 with ML-KEM-768 and ML-DSA-65	35.20 ms	23.61 ms	−32.9%
HTTP TTFB (launch to first response byte)	X25519MLKEM768 with RSA-PSS	54.83 ms	22.35 ms	−59.2%

For the corresponding X25519 with ML-KEM-768 TLS configuration using an ML-DSA-65 server certificate, the median s_client connection time (Section 3.4.2) decreased from 35.20 ms under OpenSSL 3.4.1 to 23.61 ms under OpenSSL 3.5.0, a reduction of approximately 33%. This larger change in measured connection-establishment time, compared with the mixed changes in primitive-level timings, indicates that the observed cross-version differences cannot be inferred from KEM execution times alone. The available measurements do not isolate the contributions of process initialization, TLS processing, or other software-stack components.

At the application layer, median HTTP TTFB for the hybrid X25519MLKEM768 configuration with RSA-PSS authentication decreased from 54.83 ms to 22.35 ms on the laptop across OpenSSL versions (Table 4). The TLS handshake measurements, however, used ML-DSA-65 authentication and therefore represent a different experimental configuration. These measurements cannot be combined to decompose end-to-end latency or independently quantify the contributions of key establishment, certificate authentication, or cryptographic integration. Nevertheless, the contrasting trends observed across primitive, handshake, and HTTP measurements demonstrate the importance of evaluating performance at multiple layers. In particular, the HTTP results include subprocess initialization, connection establishment, TLS processing, and application-level response handling, which are not captured by cryptographic microbenchmarks alone.

The archive also contains HTTP runs that separate the two cryptographic changes (Table 5). With RSA-PSS authentication held constant, replacing X25519 with ML-KEM-768 changed median TTFB by −14.48 ms on the laptop under OpenSSL 3.4.1, +3.43 ms on the laptop under OpenSSL 3.5.0, +0.31 ms on the lab server under OpenSSL 3.4.1, and −2.11 ms on the lab server under OpenSSL 3.5.0. With ML-KEM-768 held constant, replacing RSA-PSS with ML-DSA-65 changed median TTFB by −3.00, −2.83, +0.02, and +0.09 ms, respectively. In these loopback runs, the authentication change therefore had a smaller observed effect than the key-establishment change, and the lower full-PQC medians in Table 2 follow the key-establishment change. Each value is based on 20 measured requests from a single run. The sign of the key-establishment effect differs between hosts and releases, which indicates that it is not explained by KEM execution cost alone (Table 4); the records do not identify the responsible factor.

Table 5. Median HTTP TTFB (ms) for key-establishment- and authentication-matched configurations (20 requests per run, loopback; RSA = RSA-2048 certificate with RSA-PSS signatures). ΔKEM: ML-KEM-768 + RSA-PSS minus X25519 + RSA-PSS. ΔAuth: ML-KEM-768 + ML-DSA-65 minus ML-KEM-768 + RSA-PSS. Brackets give within-run 95% bootstrap confidence intervals. Differences are computed from unrounded medians. Source files: 20-http-openssl-classical.json, 23-http-openssl-pqc-mlkem768.json, and 35-http-openssl-fullpqc-mlkem768-mldsa65.json.

System	OpenSSL	X25519 + RSA	ML-KEM-768 + RSA	ML-KEM-768 + ML-DSA-65	ΔKEM (ms)	ΔAuth (ms)
Laptop	3.4.1	51.5	37.0	34.0	−14.48 [−16.35, −13.58]	−3.00 [−4.19, −0.92]
Laptop	3.5.0	22.1	25.5	22.7	+3.43 [+2.88, +5.02]	−2.83 [−4.55, −2.21]
Lab server	3.4.1	20.4	20.7	20.7	+0.31 [−0.03, +0.58]	+0.02 [−0.12, +0.36]
Lab server	3.5.0	16.3	14.2	14.3	−2.11 [−2.66, −1.50]	+0.09 [−0.16, +0.41]

The archive further contains HTTP runs of X25519MLKEM768 with TLS session reuse (-sess_out/-sess_in). Relative to the corresponding runs without reuse, their median TTFB changed by −4.8% to +0.3%. Because per-request resumption was not recorded, these runs describe only the observed effect of the configured reuse mode on this short-lived workload and are not a resumption benchmark.

4.3. Network Impairment and Tail-Latency Behavior

Controlled network impairment experiments show that tail latency is substantially more sensitive to packet loss than median latency (Figure 1a,b; the complete grid is given in Supplementary Table S1 of the repository [18]). At RTT = 50 ms and MTU = 1500, p99 TTFB increased from 167.9–191.9 ms at 0% loss to 1184.2–1334.6 ms at 1% loss across the three configurations, both systems, and both OpenSSL versions, an increase of 6.2–8.0×, whereas median TTFB changed by less than 0.3%. The p95 values rose from 167.2–187.8 ms to 283.5–384.9 ms.

Figure 1. Packet loss and tail latency. (a,b) p99 TTFB under OpenSSL 3.5.0 at RTT = 50 ms and MTU = 1500 for all tested loss levels; error bars are within-run 95% order-statistic confidence intervals (1000 requests per profile). (c,d) Share of requests delayed by 900–1600 ms and by 100–900 ms relative to the profile median, pooled over both systems, both OpenSSL versions, all MTUs, and all RTTs (48 profiles per configuration and loss level); error bars are 95% cluster-bootstrap confidence intervals. The dashed line in (c) is the probability that the SYN or SYN-ACK of a connection is lost.

At 0.5% loss, all twelve combinations of system, release, and configuration at least doubled their zero-loss p99 (2.9–6.7×), and four exceeded five times the baseline. The p99 at this loss level is, however, an unstable statistic: every 95% confidence interval extends from about 0.4–0.5 s to 1.2–1.3 s (Figure 1a,b), because the 99th percentile lies at the boundary between two delay classes, as explained below. Differences between configurations in p99 at 0.5% loss should therefore not be interpreted, and the loss levels at which tail amplification begins refer only to the discrete levels tested.

Figure 1c,d decomposes the tail over all 720 profiles. At every loss level, the share of requests delayed by 900–1600 ms matched the probability that at least one of the two TCP connection-establishment segments (SYN or SYN-ACK) is lost when loss p is applied independently in each direction, 1 − (1 − p)²: 0.17–0.23% versus 0.20% at 0.1% loss, 0.94–0.99% versus 1.00% at 0.5%, 1.81–2.05% versus 1.99% at 1%, and 3.76–3.91% versus 3.96% at 2%. This agreement is consistent with recovery by the 1 s initial retransmission timeout of TCP [19], which does not depend on the TLS configuration; because retransmissions were not observed directly, it does not demonstrate this mechanism. Requests delayed by 100–900 ms, which may reflect the recovery of lost data segments, were 2.3–3.5 times as frequent. With 1000 requests, p99 falls into the ≈1 s class when at least 11 requests lose a connection-establishment segment. At 0.5% loss, this has a binomial probability of 0.41, and it occurred in 56 of 144 profiles (39%), which is consistent with the bimodal p99 values at this loss level.

Differences between configurations were small. In matched profiles, the share of 100–900 ms delays for full PQC differed from classical TLS by +0.05 to +0.55 percentage points, with 95% confidence intervals that included zero at every loss level (+0.55 points, from −0.03 to +1.14, at 1% loss), and the hybrid configuration showed fewer such delays than classical TLS at 0.5% and 2% loss. The ≈1 s class was 0.24 points (0.11–0.36) more frequent for full PQC at 1% loss; at the other loss levels, the differences ranged from −0.06 to +0.14 points.

The archive also contains 47 later records that repeat nominal profiles of the classical configuration on the lab server under OpenSSL 3.4.1 (Supplementary Table S3 of the repository [18]). Their medians differed from the corresponding canonical records by up to 3.3% for RTT ≥ 20 ms and by up to 15.7% at RTT = 0 ms, whereas their p99 values at loss rates of 0.5% or more differed by factors of 0.29 to 4.55. Differences of this size in p99 between single runs under loss therefore do not indicate configuration effects by themselves.

Despite the strong increase in tail latency, failures remained uncommon: 64 of the 720,000 measured requests timed out (0, 0, 3, 8, and 53 at 0, 0.1, 0.5, 1, and 2% loss), with a maximum of 3 failures in a 1000-request profile (0.3%), always at 2% loss. The dominant operational effect of moderate loss in these experiments is therefore latency inflation rather than connection failure.

4.4. Packetization and MTU Sensitivity

The packetization summaries show how the evaluated configurations change the size and segmentation of the TLS 1.3 exchange (Figure 2, Table 6). Each capture contained seven TCP connections; the analysis uses the five test connections and excludes one connection without payload and one alert-only connection. All five test connections of a scenario produced identical segment counts and record sequences. At MTU = 1500, the server sent 4 payload-carrying TCP segments per connection for X25519 with RSA-PSS, 5 for X25519MLKEM768 or ML-KEM-768 with RSA-PSS, 10 for X25519 with ML-DSA-65, and 11 for ML-KEM-768 with ML-DSA-65. The client sent 3 segments with an X25519 key share and 4 with an ML-KEM-768 key share.

Figure 2. Packetization of the TLS 1.3 exchange under OpenSSL 3.5.0 without impairment. Left: server-to-client payload-carrying TCP segments per test connection as a function of MTU (identical for the five test connections of each scenario; a second capture session gave the same values). Right: server-to-client TLS bytes by message at MTU = 1500, including 5-byte record headers; Other comprises ChangeCipherSpec, EncryptedExtensions, Finished, two NewSessionTicket messages, and the close_notify alert. Labels: Hybrid = X25519MLKEM768, ML-KEM = ML-KEM-768, ML-DSA = ML-DSA-65, RSA = RSA-2048 with RSA-PSS. The captured connections carry no HTTP payload.

Table 6. TLS record lengths in bytes (excluding the 5-byte record header) at MTU = 1500 under OpenSSL 3.5.0, with message types inferred from the TLS 1.3 message order. RSA denotes an RSA-2048 certificate with RSA-PSS signatures. The server flight includes record headers. The last row gives server-to-client payload-carrying TCP segments per test connection at MTU = 1500/1400/1280.

Message	X25519 + RSA	X25519MLKEM768 + RSA	ML-KEM-768 + RSA	X25519 + ML-DSA-65	ML-KEM-768 + ML-DSA-65
ClientHello (client)	308	1484	1452	308	1452
ServerHello	122	1210	1178	122	1178
Certificate	779	779	779	5508	5508
CertificateVerify	281	281	281	3334	3334
ChangeCipherSpec, EncryptedExtensions, Finished	93	93	93	93	93
Server flight, ServerHello to Finished	1305	2393	2361	9087	10,143
Server payload segments	4/4/5	5/5/5	5/5/5	10/12/12	11/13/13

Table 6 attributes these differences to individual handshake messages, inferred from the TLS 1.3 message order and record lengths. The ML-KEM-768 key share enlarged the ClientHello from 308 to 1452 bytes and the ServerHello from 122 to 1178 bytes (1484 and 1210 bytes for X25519MLKEM768). ML-DSA-65 authentication enlarged the Certificate record from 779 to 5508 bytes and the CertificateVerify record from 281 to 3334 bytes, consistent with the 5478-byte certificate and the 3309-byte ML-DSA-65 signature [4]. The server handshake flight from ServerHello to Finished thus grew from 1305 bytes for classical TLS to 2393 bytes for hybrid TLS and 10,143 bytes for full PQC, of which the Certificate and CertificateVerify records accounted for 87%. Reducing the MTU to 1400 bytes increased the server segments from 10 to 12 for X25519 with ML-DSA-65 and from 11 to 13 for full PQC, with no further change at 1280 bytes, whereas the RSA-PSS configurations remained at 4–5 segments.

Because the packetization captures were taken without impairment, they show exposure to loss rather than loss outcomes. The full-PQC server flight requires at least 7–9 maximum-size segments instead of 1–2, so more segments can be lost. In the network-impairment experiments, however, the observed increase in loss-induced delays was small and statistically uncertain (Section 4.3): the tail consisted mainly of ≈1 s delays whose frequency is consistent with connection-establishment losses common to all configurations, and the share of 100–900 ms delays for full PQC differed from that of classical TLS by +0.05 to +0.55 percentage points, with confidence intervals that included zero. Individual p99 comparisons can suggest larger effects but are unstable. For example, on the laptop under OpenSSL 3.4.1 at RTT = 50 ms and 0.5% loss, full-PQC p99 TTFB increased from 555.8 ms at MTU = 1500 to 1189.5 ms at MTU = 1280, whereas classical p99 decreased from 1193.2 to 649.1 ms under the same conditions. Such differences are consistent with whether the p99 of a profile falls into the ≈1 s delay class and are not evidence of an effect of MTU or authentication. Because the binary captures were not retained, retransmissions could not be counted directly.

4.5. Capacity and Concurrency

Concurrency experiments showed higher completed-request rates and lower tail TTFB after migration to OpenSSL 3.5.0 (Figure 3 and Figure 4). Requests per second (RPS) are the successful measured requests divided by the wall-clock duration of the measured batch, including executor queueing. At concurrency levels c = 50 to 200, RPS increased by approximately 46–58% across the classical, hybrid, and full-PQC configurations. For example, at c = 50, RPS increased from 95.8 to 148.2 for classical TLS, from 92.3 to 146.1 for the hybrid configuration, and from 92.2 to 141.4 for full PQC (Figure 3).

Figure 3. Completed requests per second (RPS) as a function of the maximum number of concurrent client workers c on the laptop platform. RPS is the number of successful measured requests divided by the wall-clock duration of the 1000-request measured batch, including executor queueing; each request used a new s_client process and TLS connection. Dashed lines: OpenSSL 3.4.1; solid lines: OpenSSL 3.5.0.

Figure 4. p99 TTFB as a function of the maximum number of concurrent client workers c on the laptop platform. TTFB is measured from the launch of each s_client subprocess to the first response byte and excludes the time a request waited for a worker. Error bars are within-run 95% order-statistic confidence intervals. Dashed lines: OpenSSL 3.4.1; solid lines: OpenSSL 3.5.0.

The same pattern was observed for p99 TTFB, measured from the launch of each client subprocess to the first response byte and therefore excluding executor queueing (Figure 4). At c = 50, p99 TTFB decreased from 823.1 to 404.8 ms for classical TLS, from 867.5 to 425.9 ms for hybrid TLS, and from 860.0 to 449.5 ms for full PQC. At c = 200, p99 TTFB remained approximately half of the OpenSSL 3.4.1 value.

Across the evaluated concurrency levels, OpenSSL 3.5.0 consistently achieved higher RPS and lower p99 TTFB than OpenSSL 3.4.1 for classical, hybrid, and full-PQC configurations. The similar trends across these configurations indicate that the observed cross-version differences are not confined to post-quantum cryptographic workloads. However, because each request launched a new client subprocess and client and server shared the same host resources, these measurements characterize the combined benchmark workload rather than isolated server-side capacity. Furthermore, the experiments do not identify the specific causes of the performance improvements or establish steady-state production capacity. The results should therefore be interpreted as descriptive comparisons under the evaluated single-host conditions. At c = 200, the measured batch lasted only 7.0–10.9 s, so start-up and draining periods form a non-negligible part of each measurement.

4.6. Discussion and Synthesis

The cross-version results show that application-level post-quantum TLS performance cannot be inferred from cryptographic primitive timings alone. OpenSSL 3.5.0 yielded lower HTTP TTFB than OpenSSL 3.4.1 across all three evaluated configurations, despite mixed changes in X25519MLKEM768 primitive timings (Table 2 and Table 4). As discussed in Section 4.1, these differences describe complete software configurations, and the two OpenSSL 3.5.0 hybrid runs indicate run-to-run variation rather than provider overhead (Table 3). In authentication-matched runs, replacing RSA-PSS with ML-DSA-65 changed loopback TTFB by −3.00 to +0.09 ms (Table 5).

Transport conditions dominated the tail. At 1% loss, p99 TTFB increased 6–8-fold in all configurations. Most of the excess consisted of delays of about 1 s, whose frequency is consistent with the loss of TCP connection-establishment segments (Figure 1). ML-DSA-65 authentication enlarged the server handshake flight seven- to eightfold and the number of server segments two- to threefold (Figure 2, Table 6). In the tested conditions, however, the observed differences in loss-induced delays between configurations were small, and for delays of 100–900 ms, their confidence intervals included zero.

Concurrency experiments further showed higher RPS and lower p99 TTFB under OpenSSL 3.5.0 across classical, hybrid, and full-PQC configurations (Figure 3 and Figure 4). These results characterize a co-located client–server workload with a new client process and TLS connection per request, rather than isolated production-server capacity. Taken together, the findings highlight the importance of evaluating post-quantum TLS across cryptographic, protocol, transport, and workload layers instead of relying exclusively on primitive-level benchmarks or ideal-network measurements.

The deployment implications of these experiments are restricted to short-lived HTTP/1.1 requests with a fresh TLS connection, a new OpenSSL client process, and a single self-signed server certificate per observation; realistic certificate chains would add further authentication bytes. They do not quantify persistent-connection or session-resumption performance. For applications such as encrypted video delivery and video surveillance, larger TLS authentication material could influence connection setup and initial content delivery, but video playback-startup latency and streaming throughput were not measured here. TLS protects communication between transport endpoints, whereas the security of separately encrypted video content also depends on the content-encryption design. The cryptanalysis of a video cryptosystem by Lin et al. [20] illustrates this separate application-layer concern but is not a TLS performance benchmark.

4.7. Limitations of the Historical Dataset

The results are derived from a historical measurement archive whose original hosts and software installations are no longer available. Several controls could therefore not be added after the measurements were taken.

First, most conditions were recorded once, and the baseline HTTP comparisons in Table 2, Table 3 and Table 5 rest on 20 measured requests per run. The reported confidence intervals describe sampling uncertainty within a run; they do not include run-to-run variation, which the 47 repeated impairment records show to be substantial for p99 under loss. Independent, randomized, or interleaved repetitions would be required to establish the reliability of the small baseline differences, the confidence intervals, and the tail-latency values.

Second, TTFB was measured from the launch of a client process to the first response byte. Separate timestamps for process initialization, TCP establishment, and TLS completion were not recorded, and neither a fixed-response server nor a persistent-client control was used.

Third, binary packet captures were not retained, so delayed requests could not be linked to observed retransmissions or recovery events, and the TCP mechanisms discussed in Section 4.3 remain inferences from timing.

Fourth, the concurrency experiments used co-located clients and server, short measurement batches, and no resource measurements. They therefore cannot identify the saturated component or characterize steady-state capacity.

Finally, the liboqs version, source commits, and build settings of the original installations were not recorded, so the provider that executed each algorithm cannot be verified for the archived runs. The conclusions of this study are limited to descriptive observations of the evaluated configurations under these conditions.

5. Conclusions

This study evaluated post-quantum TLS performance at the cryptographic, protocol, application, transport, and concurrent-workload levels, using a measurement archive that is released with this article. OpenSSL 3.5.0 showed lower HTTP TTFB than OpenSSL 3.4.1 for classical, hybrid, and full-PQC configurations on both platforms. For hybrid X25519MLKEM768, the median TTFB overhead relative to classical TLS was 6.5–7.5% with OpenSSL 3.4.1 and 1.2–1.3% with OpenSSL 3.5.0. Each median is based on 20 requests from one run, and the latter overhead is of the same order as the difference between two runs of one configuration. As discussed in Section 4.1, these cross-version results describe complete software configurations. In authentication-matched runs, replacing RSA-PSS with ML-DSA-65 changed loopback TTFB by −3.0 to +0.1 ms, although ML-DSA-65 enlarged the server handshake flight to 9.1–10.1 kB, compared with 1.3–2.4 kB with RSA-PSS. Under controlled impairment, 1% packet loss increased p99 TTFB 6–8-fold at RTT = 50 ms and MTU = 1500 bytes. The tail consisted mainly of delays of about 1 s, whose frequency was consistent with the loss of TCP connection-establishment segments and was similar across configurations. Under the co-located concurrent workload, OpenSSL 3.5.0 completed more requests per second and showed lower p99 TTFB. These results are subject to the limitations of the historical dataset described in Section 4.7. Future work should repeat the measurements with independent runs, phase-level timestamps, retained packet captures, realistic certificate chains, connection reuse and resumption, and separate client and server resources.