The Colossus with Feet of Clay: Debunking Encrypted Traffic Classifiers under PQC Evolution

The Colossus with Feet of Clay: Debunking Encrypted Traffic Classifiers under PQC Evolution B

Bingzhen Li1 , Lingjia Meng2, , Runhan Song2 , Chuanzhou Pan2 , Tongjun Pu3 , Ziqiang Ma3 , Yupeng Jiang1 , Lei Cui2 , Zhiyu Hao2 1 School of Cyber Science and Technology, Beihang University, Beijing, China 2 Zhongguancun Laboratory, Beijing, China

arXiv:2608.22683v1 [cs.CR] 24 Aug 2026

3 School of Information Engineering, Ningxia University, Ningxia, China

Abstract—Encrypted traffic classifiers often achieve high accuracy under matched training and testing conditions, implicitly assuming that deployment traffic follows the training distribution. TLS migration toward post-quantum cryptography (PQC) challenges this assumption because hybrid key establishment can reshape observable traffic without changing application labels. We frame this change as PQC-induced protocol drift and study its effects through closed-world HTTPS website fingerprinting using the deployed TLS 1.3 Hybrid-PQC group X25519MLKEM768. We build a controlled, PQC-aware benchmark pairing Traditional (Non-PQC) and Hybrid-PQC traffic, then evaluate five representative classifiers and side-channel representations under matched-domain, cross-domain, and deployment-ratio settings. Collectively, the experiments show that PQC evolution does not remove learnable website information. Instead, it changes how that information appears in traffic, causing classifiers and feature combinations that perform well in-domain to lose reliability across cryptographic domains. By exposing the fragility of matched-domain evaluation, we offer strategic guidance, identify cross-domain robustness as a research priority, and recommend protocol-aware practices for dependable real-world encrypted traffic classification. The code is available at http://anonymous. 4open.science/r/PQ-WF-Eval. Index Terms—Encrypted Traffic Classification, Post-Quantum Cryptography, Protocol Drift, Website Fingerprinting.

I. Introduction Encrypted traffic classifiers are typically evaluated with training and test traffic drawn from the same distribution, implicitly assuming that this distribution remains representative after deployment [1]–[3]. One representative security task in this area is closed-world HTTPS website fingerprinting (WF) [4], [5], in which a passive adversary infers the visited website without decrypting TLS payloads. The adversary does so by exploiting packet lengths, directions, timing, and byte-level packet representations [6]–[10]. Under matched training and testing conditions, prior WF methods have reported high classification accuracy. Such results, however, do not establish whether classifiers remain reliable as the underlying cryptographic protocol stack evolves. The deployment of post-quantum cryptography (PQC) provides a concrete instance of this evolution. TLS migration currently centers on hybrid key establishment, which combines a traditional key exchange with a PQC key-encapsulation mechanism (KEM) [11], [12]. We focus on the deployed TLS 1.3 Hybrid-PQC group X25519MLKEM768. Compared with the Traditional (Non-PQC) X25519, this group introduces

substantially larger key shares and expands the corresponding handshake messages. These additional bytes can alter TCP segmentation, packet positions, and timing [13]–[15]. Thus, although the website label is unchanged, the key-establishment mechanism can reshape the observable traffic trace used for classification. Distribution drift arises when the traffic distribution observed during deployment differs from that represented in the training data. Within this broader category, we define protocol drift as shifts in traffic distribution resulting from the evolution or deployment of protocol mechanisms. Unlike temporal, network, or application drift, protocol drift alters the traffic-generation process under otherwise fixed experimental conditions [14], [16]–[18]. The transition from Traditional (Non-PQC) X25519 to Hybrid-PQC X25519MLKEM768 key establishment provides a concrete instance of PQC-induced protocol drift. We examine its effects through closed-world HTTPS website fingerprinting. Accordingly, this study investigates how the transition to PQC in TLS affects the reliability of encrypted traffic classifiers. This transition presents two closely related challenges for evaluating encrypted traffic classifiers. • Representation shifts despite stable task semantics. The larger key shares introduced by PQC key establishment increase TLS handshake message sizes and may alter packet-length sequences, burst boundaries, TCP segmentation, and byte-level alignment [11], [15], [19]. These changes reshape classifier inputs even though the website label and application semantics remain unchanged. Classifiers may consequently learn configuration-specific correlations that fail to transfer across cryptographic domains. • Deployment heterogeneity and cross-domain mismatch. The Internet is unlikely to transition directly from Traditional key establishment to a single PQC configuration. Traditional, Hybrid-PQC, and future Pure-PQC mechanisms may therefore coexist throughout an extended migration period [3], [13]. Once deployed, a classifier trained in one cryptographic domain may encounter traffic from a mixture of configurations, some absent from its training data. Matched-domain accuracy alone cannot characterize this mismatch or its sensitivity to the HybridPQC deployment ratio.

We examine these effects using a controlled, PQC-aware encrypted traffic benchmark. First, we measure the deployment of TLS key-establishment mechanisms across 2,060 Trancoranked websites and select the 200 highest-ranked websites supporting X25519MLKEM768 as collection candidates [20], [21]. After validation, 195 websites remain in the shared label set. For each retained website and cryptographic configuration, we collect 120 complete visits, which form the Non-PQC Website Dataset and PQC Website Dataset, respectively. Four Mixed test sets, together with the two endpoint test sets, span six Hybrid-PQC deployment ratios from 0% to 100%. Under a common closed-world WF task with visit-level partitions, we evaluate CUMUL, DF, Tik-Tok, ET-BERT, and YaTC while retaining their native inputs and preprocessing pipelines [6]–[10]. The evaluation examines matched-domain learnability, bidirectional cross-domain transfer, sensitivity to Hybrid-PQC deployment ratios, and the contributions of sidechannel features. Matched-domain results show that website identity remains learnable in either cryptographic domain. Each classifier achieves comparable performance in the two matched-domain settings. For example, ET-BERT achieves accuracies of 0.9316 and 0.9332, while YaTC obtains 1.0000 and 0.9991. This learnability, however, does not ensure cross-domain reliability. When models trained on Non-PQC traffic are applied to HybridPQC traffic, the accuracies of CUMUL, ET-BERT, and YaTC drop from 0.7731, 0.9316, and 1.0000 to 0.1919, 0.6255, and 0.3582, respectively. We next examine how this mismatch changes during migration. As the Hybrid-PQC deployment ratio increases, performance declines monotonically for four classifiers, whereas YaTC follows a non-monotonic trajectory; none maintains its Non-PQC baseline across the full range. Finally, controlled comparisons of side-channel representations show that packet length is the most discriminative individual feature, although its advantage diminishes as the Hybrid-PQC deployment ratio increases. Direction and timing provide limited additional benefit. Overall, PQC migration creates classifier mismatch without eliminating learnable website information. The main contributions are as follows. • PQC-aware traffic benchmark for isolating protocol drift. To the best of our knowledge, we introduce the first encrypted traffic benchmark designed to isolate distribution shifts induced by PQC key establishment. Its paired NonPQC and Hybrid-PQC datasets and controlled Mixed test sets support evaluation across cryptographic domains and deployment ratios while holding the label space and visitlevel partitions fixed. • Systematic evaluation of cross-domain classifier reliability under PQC-induced protocol drift. We assess five representative classifiers spanning aggregate statistics, packet sequences, timing-aware inputs, and pre-trained byte-level representations. Contrasting matched-domain and cross-domain performance separates domain-specific learnability from transfer reliability. • Controlled analysis of side-channel feature transferability. Using DF as a fixed architecture, we isolate the

individual and combined contributions of packet direction, length, and timing. Packet length remains the strongest individual feature, yet no evaluated feature composition prevents cross-domain degradation. These findings offer practical guidance for feature engineering in traffic analysis as cryptographic protocols evolve. The remainder of this paper is organized as follows. Section II reviews background and related work. Section III analyzes PQCinduced changes in TLS 1.3 traffic and formulates the corresponding hypotheses. Section IV describes the construction of the PQC-aware benchmark. Section V evaluates representative classifiers under PQC-induced protocol drift, Section VI discusses the implications, and Section VII concludes the paper. II. Background and Related Work A. Post-Quantum Key Establishment and Deployment in TLS The security of widely deployed public-key mechanisms, including RSA and elliptic-curve cryptography, depends on the hardness of integer factorization or discrete logarithms [22], [23]. Shor’s algorithm solves both problems in polynomial time on a sufficiently capable quantum computer [24]. A cryptographically relevant quantum computer does not yet exist, but migration is already time-sensitive. An adversary can record long-lived encrypted traffic today and decrypt it after such a computer becomes available, a threat commonly described as “harvest now, decrypt later” [21]. NIST responded to this threat through its Post-Quantum Cryptography standardization project. In August 2024, NIST finalized ML-KEM in FIPS 203, ML-DSA in FIPS 204, and SLH-DSA in FIPS 205 [11], [19], [25]. ML-DSA and SLHDSA provide digital signatures, whereas ML-KEM provides the key-establishment primitive relevant to this study. ML-KEM is derived from CRYSTALS-Kyber [26] and offers three parameter sets: ML-KEM-512, ML-KEM-768, and ML-KEM-1024. A key-encapsulation mechanism comprises three algorithms: key generation (KeyGen), encapsulation (Encaps), and decapsulation (Decaps). Together, these algorithms allow two endpoints to establish a shared secret over a public channel [11], [12]. TLS 1.3 can supply that secret to its existing key schedule without changing the subsequent symmetric record-protection mechanisms. ML-KEM can therefore replace a traditional Diffie–Hellman exchange or be combined with one during migration. Current web deployment is increasingly centered on hybrid key establishment [27]. A post-quantum/traditional hybrid combines a post-quantum mechanism with a traditional key exchange [13], [21]. Its combiner aims to preserve security if at least one component remains unbroken, subject to the stated security assumptions. The TLS hybrid group studied in this paper, X25519MLKEM768, combines X25519 with MLKEM-768 [28]. Recent browser and TLS-stack deployments have enabled this group by default, making it a practical target for studying protocol evolution rather than a hypothetical configuration [27]. Throughout this paper, we distinguish three key-establishment settings to maintain a precise experimental scope. Traditional

2

(Non-PQC) key establishment uses X25519 without a postquantum component, providing the baseline for our paired collections. Hybrid-PQC combines X25519 with ML-KEM768 through X25519MLKEM768 and defines the empirical PQC domain evaluated in this work. Pure-PQC uses standalone ML-KEM key establishment and remains an active IETF specification effort [29].1

explicit choices about trace length, padding, truncation, and positional alignment. Overall, sequence representations replace extensive feature construction with end-to-end learning over a defined packet-level observation surface. Raw-byte representations and pre-trained models. Rawbyte representations retain selected packet headers and encrypted payload bytes instead of reducing each packet to a small set of side-channel measurements [40], [41]. Early convolutional methods showed that discriminative traffic features can be learned directly from byte sequences without manually defined flow statistics [42]. This richer observation surface also requires careful preprocessing because identifiers, protocol fields, packet selection, and truncation can introduce dataset-specific artifacts [1]. Pre-training changes how these representations are learned rather than defining a separate input category. It first learns reusable patterns from large unlabeled traffic corpora and then adapts the resulting encoder to labeled downstream tasks [43]–[45]. ET-BERT pre-trains a Transformer over contextualized datagram representations, while YaTC uses masked autoencoding to learn a multilevel flow representation [9], [10]. These models combine information-rich inputs with self-supervised learning, but the quality of their transfer still depends on the relationship between pre-training and downstream distributions [2]. LLMbased approaches further extend this learning strategy through traffic-specific tokenization, instruction tuning, and open-set learning [46]–[48]. Overall, raw-byte processing determines what information is exposed, whereas pre-training determines how reusable features are acquired from that information.

B. Encrypted Traffic Classifiers: Representations and Learning Paradigms Encrypted traffic classifiers infer application, service, or activity labels from observable traffic without decrypting application payloads [1], [30], [31]. Their effectiveness depends on both the learning architecture and the representation supplied to that architecture. Existing methods span hand-crafted flow statistics, ordered packet sequences, raw bytes, and transferable representations learned through self-supervision [32]. These approaches coexist because they offer different balances among information coverage, computational cost, interpretability, and data requirements. We therefore organize prior work primarily by input representation, while treating pre-training as a learning strategy layered on byte-level or structured traffic inputs. Aggregate statistical representations. Statistical methods summarize a flow using a fixed feature vector before classification. Common features include packet and byte counts, flow duration, packet-length distributions, direction ratios, burst statistics, and inter-arrival times [32], [33]. These features are typically combined with lightweight classifiers such as support vector machines, decision trees, random forests, or nearest-neighbor methods [34], [35]. Feature selection and normalization can reduce dimensionality and improve efficiency, but they require substantial domain knowledge and careful dataset-specific tuning. CUMUL is a representative method that combines summary statistics with a sampled cumulative curve derived from direction-coded packet lengths [6]. The curve preserves the progression of transferred volume while maintaining a compact, fixed-dimensional representation. Statistical methods remain attractive for their efficiency and interpretability, although their performance depends strongly on manual feature design [36]. Packet-sequence representations. Sequence-based methods retain packet ordering and allow a model to learn spatial or temporal dependencies directly from a trace [37]. This approach reduces reliance on manual aggregation while preserving patterns that fixed statistical vectors may obscure. Prior work has explored recurrent sequence encoders and image-like transformations of packet sizes and arrival times [38], [39]. DF uses one-dimensional convolutions to learn local motifs and hierarchical patterns from direction-coded packet traces [7]. Tik-Tok extends directional modeling with timing information, enabling the classifier to capture temporal dependencies beyond packet order alone [8]. These models can represent finer traffic structure than aggregate statistics, but their inputs require

C. Distribution Drift in Encrypted Traffic Classification Distribution drift refers to a mismatch between the traffic distributions observed during model training and deployment [18], [31], [53]. Such mismatches can arise from collection time, network paths, client platforms, service evolution, data pipelines, or the protocol stack itself. They can therefore undermine deployment reliability even when a classifier performs well under mismatched experimental conditions. Table I summarizes these sources and distinguishes how each is controlled or studied in this work. Prior studies show that encrypted traffic classifiers often learn regularities tied to their collection environments. Crossenvironment evaluations report degradation across time, vantage points, and client settings [49], [50]. Other work examines application evolution, unknown-pattern discovery, and dataset instability [18], [52], [53]. Wickramasinghe et al. further show that inputs, sanitization and sample granularity can materially affect reported conclusions [1]. Comparatively less work isolates the evolution of the protocol stack as an independent source of distribution drift. Within this taxonomy, we define protocol drift as shifts in traffic distribution resulting from the evolution or deployment of protocol mechanisms. Unlike temporal, network, or application drift, protocol drift alters the traffic-generation process even when labels, clients, vantage points, and collection pipelines are held constant. It can arise from changes to TLS extensions,

1 We include Pure-PQC only as a protocol-level reference in Section III; we neither collect Pure-PQC traffic nor extrapolate our Hybrid-PQC results to that setting.

3

TABLE I: Taxonomy of Distribution-Drift Sources in Encrypted Traffic Classification Drift Type

Sources of Variation

Prior Focus

Control or Scope in This Study

Temporal Drift

Web content, server or CDN updates, third-party resources, and collection time.

Cross-time degradation, resampling, and model updating [18], [49].

Adjacent, alternating Non-PQC and PQC collections limit temporal confounding.

Network Drift

Vantage points, ISPs or ASNs, routing, RTT, loss, and bandwidth.

Cross-vantage and open-world generalization [49], [50].

A fixed vantage point controls path and access-network variation.

Client Drift

Browsers, operating systems, TLS libraries, transport stacks, caching, and loading strategies.

Robustness across clients and software stacks [49].

The client platform, protocol stack, cache state, and scripts remain fixed.

Application Drift

Version updates, API migrations, and server-side logic.

Self-evolving classification, unknownpattern discovery, and open-world adaptation [51], [52].

Website labels and access tasks remain unchanged across collections.

Pipeline Drift

Collection, segmentation, labels, sanitization, truncation, and data splits.

Benchmark comparability, reproducibility, and dataset stability [1], [3], [53].

Labels, splits, and metrics are unified; native model inputs are disclosed.

Protocol Drift

TLS or QUIC versions, extensions, key exchange, and transport migration.

Protocol measurement, handshake overhead, and implementation fingerprinting [54]–[56].

PQC key establishment is varied while other collection factors are controlled.

Client

key-establishment algorithms, encrypted handshake mechanisms [57], or migration to QUIC and HTTP/3 [5]. Prior measurement studies show that protocol design and implementation choices can alter observable traffic patterns and performance characteristics [54]–[56]. This paper examines PQC evolution as a concrete instance of protocol drift, focusing on the TLS 1.3 transition from X25519 to hybrid X25519MLKEM768 key establishment. The resulting changes to the handshake material may affect packet segmentation, timing, and the byte-level representations used as inputs to encrypted traffic classifiers.

Server

1. Generate a ephemeral ECDH key pair. private key: dc (32B) public key: Qc = dc · G (32B)

ClientHello KeyShare: Qc (32B) supported_groups: x25519

2. Select group and generate a ephemeral ECDH key pair. private key: ds (32B) public key: Qs = ds · G (32B)

III. PQC-Induced Protocol Drift in TLS 1.3 Traffic

ServerHello KeyShare: Q s (32B) supported_groups: x25519

A. Comparison of TLS 1.3 Key-Establishment Modes 1) Traditional (Non-PQC) Key Establishment: The Traditional (Non-PQC) mode considered in this paper uses ephemeral X25519 Diffie–Hellman for key establishment in TLS 1.3 [14]. During the handshake, the client and server exchange ephemeral key shares and independently derive the same shared secret. The TLS 1.3 key schedule incorporates this secret through HKDF-based extraction and expansion to derive handshake and application traffic secrets and, ultimately, traffic keys [14], [58]. In the ClientHello, the client advertises acceptable named groups in the supported_groups extension and typically supplies a KeyShareEntry for one or more of these groups in the key_share extension. The server selects a mutually supported group and returns the corresponding key share in the ServerHello. If the client has not supplied a key share for a group selected by the server, the server can instead send a HelloRetryRequest. TLS 1.3 supports ellipticcurve groups, such as secp256r1 and x25519, as well as finite-field Diffie–Hellman groups. Our Traditional baseline uses x25519, whose key share is 32 bytes [14].

3. Compute shared secret. SS = dc · QS (32B)

3. Compute shared secret. SS = ds · Qc (32B)

Fig. 1: Traditional (Non-PQC) X25519 key establishment in TLS 1.3.

As illustrated in Fig. 1, we express X25519 using conventional ECDH notation and let 𝐺 denote the fixed base point. The client generates an ephemeral private scalar 𝑑 𝑐 , computes the corresponding key share 𝑄 𝑐 = 𝑑 𝑐 · 𝐺, and sends 𝑄 𝑐 in the ClientHello. After selecting x25519, the server generates 𝑑 𝑠 , computes 𝑄 𝑠 = 𝑑 𝑠 ·𝐺, and returns 𝑄 𝑠 in the ServerHello. The client derives 𝑆𝑆X25519 = 𝑑 𝑐 · 𝑄 𝑠 , while the server derives 𝑆𝑆X25519 = 𝑑 𝑠 · 𝑄 𝑐 . Both computations yield 𝑆𝑆X25519 = 𝑑 𝑐 · 𝑑 𝑠 · 𝐺, which is then supplied to the TLS 1.3 key schedule. 2) Hybrid-PQC Key Establishment: RFC 9954 defines a framework for hybrid key exchange in TLS 1.3, in which a

4

Client

Server

Client

1. Generate two sets of keys. ECDH: dc (32B), Qc (32B) ML-KEM: skc (2400B), pkc (1184B)

Server

1. Generate ML-KEM key pair. encapsulate key: pk (1184B) decapsulate key: sk (2400B)

ClientHello KeyShare: pkc || Qc (1216B) supported_groups: X25519MLKEM768

ClientHello KeyShare: pk (1184B) supported_groups: mlkem768

2. Generate ECDH key pair and ML-KEM encap. ECDH: ds (32B), Qc (32B) ML-KEM: ct (1088B), SSmlkem (32B) = ML-KEM.Encaps(pkc )

2. Execute ML-KEM.Encaps(). ct (1088B), SS (32B) = ML-KEM.Encaps(pk)

ServerHello KeyShare: ct || Qs (1120B) supported_groups: X25519MLKEM768

ServerHello KeyShare: : ct (1088B) supported_groups: mlkem768

3. Decrypt encrypted text. SSmlkem (32B) = ML-KEM.Decaps(skc , ct ) 4. Compute shared secret. SSecdh (32B) = dc · QS Hybrid shared security: SSmlkem || SSecdh

4. Compute shared secret. SSecdh (32B) = ds · Qc Hybrid shared security: SSmlkem || SSecdh

3. Execute ML-KEM.Decaps(). SS (32B) = ML-KEM.Decaps(sk, ct)

Fig. 2: Hybrid-PQC X25519MLKEM768 key establishment in TLS 1.3.

Fig. 3: Pure-PQC MLKEM768 key establishment in TLS 1.3.

groups are MLKEM512, MLKEM768, and MLKEM1024, corresponding to the standardized ML-KEM parameter sets [11]. We use MLKEM768 for the protocol-level comparison because it matches the KEM parameter set in X25519MLKEM768; consistent with the scope defined in Section II, Pure-PQC is not included in the empirical evaluation. As illustrated in Fig. 3, the client generates an ML-KEM encapsulation/decapsulation key pair ( 𝑝𝑘, 𝑠𝑘) and sends the encapsulation key 𝑝𝑘 in the key_share extension of the ClientHello. The server runs Encaps with 𝑝𝑘 to produce a ciphertext 𝑐𝑡 and a shared secret 𝑆𝑆MLKEM , then returns 𝑐𝑡 in the ServerHello. The client runs Decaps with 𝑠𝑘 and 𝑐𝑡 to recover the same shared secret. This secret is supplied directly to the TLS 1.3 key schedule in place of an (EC)DHE shared secret. 4) Comparison of Key-Establishment Modes: Table II compares the three TLS 1.3 key-establishment modes by their KeyShareEntry sizes and cryptographic operations. The Traditional (Non-PQC) mode exchanges 32-byte X25519 key shares in both directions. Hybrid-PQC (X25519MLKEM768) increases the client and server entries to 1216 and 1120 bytes, respectively, by combining X25519 with ML-KEM-768. PurePQC (MLKEM768) removes the X25519 component and uses an 1184-byte encapsulation key from the client and a 1088byte ciphertext from the server. Thus, Pure-PQC reduces each entry by 32 bytes relative to Hybrid-PQC, but both PQC modes carry substantially larger key-establishment payloads than the Traditional baseline. These larger key-establishment payloads increase the sizes of the ClientHello and ServerHello. When a serialized handshake flight exceeds the negotiated TCP Maximum Segment Size (MSS), the TCP stack distributes its bytes across multiple segments. The additional segments can increase the observable packet count and incur additional transmission and

traditional key-exchange component and a post-quantum KEM component are represented by a single named group [13]. The component key_exchange values are concatenated within each KeyShareEntry, and the concatenated shared secret is supplied to the TLS 1.3 key schedule in place of the conventional (EC)DHE secret. This construction is designed to preserve security as long as at least one component remains secure. The draft-ietf-tls-ecdhe-mlkem-05 defines three hybrid named groups that combine an ellipticcurve Diffie–Hellman group with an ML-KEM parameter set [28]. Among them, X25519MLKEM768 is marked Recommended=Y and is the Hybrid-PQC configuration studied in this paper. Its client KeyShareEntry contains a 1184-byte ML-KEM-768 encapsulation key followed by a 32-byte X25519 key share, for a total of 1216 bytes. Its server entry contains a 1088-byte ML-KEM-768 ciphertext followed by a 32-byte X25519 key share, for a total of 1120 bytes. As illustrated in Fig. 2, the client generates an X25519 key pair (𝑑 𝑐 , 𝑄 𝑐 ) and an ML-KEM key pair ( 𝑝𝑘 𝑐 , 𝑠𝑘 𝑐 ), and sends 𝑝𝑘 𝑐 ∥ 𝑄 𝑐 in the ClientHello. The server generates (𝑑 𝑠 , 𝑄 𝑠 ), runs Encaps with 𝑝𝑘 𝑐 to obtain (𝑐𝑡, 𝑆𝑆MLKEM ), and returns 𝑐𝑡 ∥ 𝑄 𝑠 in the ServerHello. The client runs Decaps with 𝑠𝑘 𝑐 and 𝑐𝑡 to recover 𝑆𝑆MLKEM . Both endpoints also derive 𝑆𝑆X25519 from their X25519 key pairs. The two component secrets are concatenated in the specified order: 𝑆𝑆hybrid = 𝑆𝑆MLKEM ∥ 𝑆𝑆X25519 ,

(1)

and the resulting 64-byte hybrid shared secret is supplied to the TLS 1.3 key schedule. 3) Pure-PQC Key Establishment: Pure-PQC key establishment removes the conventional (EC)DHE exchange and uses ML-KEM within the standard TLS 1.3 handshake flow. This mechanism and its associated named groups are specified in the IETF draft draft-ietf-tls-mlkem-09 [29]. These

5

TABLE II: Comparison of TLS 1.3 key-establishment modes. Mode

Composition

Client / Server KeyShare Size

Traditional (Non-PQC)

X25519

Hybrid-PQC Pure-PQC

Cryptographic Operations

Characteristics

32 B / 32 B

X25519 key generation + shared-secret computation

Compact key shares with no post-quantum component

X25519 + ML-KEM-768

1216 B / 1120 B

X25519 + ML-KEM (KeyGen, Encaps, Decaps)

Retains X25519 and adds ML-KEM, increasing the KeyShare sizes

ML-KEM-768

1184 B / 1088 B

ML-KEM (KeyGen, Encaps, Decaps)

Uses standalone ML-KEM without a traditional component

retransmission costs. Together, these protocol-level changes modify the observable side-channel surface of encrypted traffic. Larger KeyShareEntry values can change packet-length sequences, burst structure, timing, TLS-record boundaries, and byte-level alignment—all of which are inputs to the traffic classifiers studied in this paper. The next subsection analyzes these effects across four feature dimensions.

expanded messages cross TLS record or TCP segment boundaries, they can also shift the positions of subsequent packets within a fixed-length trace. These changes affect both packetlength distributions and cumulative byte curves, including the representation used by CUMUL. Packet direction (𝐷). Hybrid-PQC does not change the logical directions of the ClientHello and ServerHello. Instead, larger handshake messages may be carried in more TCP segments. If preprocessing retains these segments and their acknowledgments, the number and positions of client-to-server and server-to-client packets can change within the first 𝑁 observations. Even when pure ACKs are removed, longer runs of same-direction data packets can alter burst boundaries and uplink–downlink patterns. The effect on 𝐷 therefore depends on both TCP segmentation and the packet-filtering policy used by the classifier. Timing (𝑇). Timing changes can arise from both transmission and cryptographic processing. Additional handshake bytes require more serialization and may introduce extra segments, acknowledgments, or retransmissions under constrained network conditions. Hybrid-PQC also adds ML-KEM KeyGen, Encaps, and Decaps operations to the X25519 computation. Their relative cost depends on the implementation, hardware, and available acceleration, so it should not be assumed to exceed X25519 in every deployment. Together, these factors may shift packet IATs and handshake-phase duration, particularly on bandwidth-limited paths or resource-constrained endpoints. Unlike the deterministic increase in keying-material size, the magnitude of timing drift is therefore environment-dependent. Byte-level packet representation (𝑃). Hybrid-PQC changes both the content and length of the key_share extension. The client entry concatenates the ML-KEM-768 encapsulation key with the client’s 32-byte X25519 ephemeral key share. The server entry concatenates the ML-KEM-768 ciphertext with the server’s 32-byte X25519 ephemeral key share. These fields change the byte sequence and offsets within the corresponding handshake messages. Larger messages may also cross TLS record and TCP segment boundaries at different positions, shifting the alignment of later bytes. Under fixed or truncated observation windows, a classifier may therefore capture different portions of the handshake and subsequent encrypted records. Pre-trained encoders such as ET-BERT and YaTC can consequently receive familiar protocol fields at new offsets or

B. PQC-Induced Changes Across Four Feature Dimensions We represent the observable traffic trace generated by a single HTTPS website visit as a 4-tuple: 𝑋 = (𝐿, 𝐷, 𝑇, 𝑃)

(2)

Here, 𝐿 is the packet-length sequence, 𝐷 is the corresponding packet-direction sequence, and 𝑇 contains packet timestamps or inter-arrival times (IATs). The fourth component, 𝑃, denotes a generalized byte-level packet representation. In this paper, 𝑃 may include sanitized network and transport headers, TLS handshake bytes, and encrypted application records, but it excludes plaintext application-layer content. This formulation covers the native inputs of the classifier families evaluated later. CUMUL, DF, and Tik-Tok derive their inputs primarily from combinations of 𝐿, 𝐷, and 𝑇 [6]–[8]. By comparison, ETBERT and YaTC consume richer byte-oriented representations captured by 𝑃 [9], [10]. The 4-tuple therefore separates compact side-channel sequences from selected packet bytes without assuming that all classifiers observe the same input fields. Relative to Traditional (Non-PQC) X25519 key establishment, Hybrid-PQC adds an ML-KEM-768 encapsulation key to the ClientHello and an ML-KEM-768 ciphertext to the ServerHello. As summarized in Table II, these additions originate in the key_share extension but propagate through TLS record construction and TCP segmentation. Their effects differ across feature dimensions and depend partly on each classifier’s preprocessing pipeline. Packet length (𝐿). The ML-KEM-768 encapsulation key and ciphertext are substantially larger than the 32-byte X25519 key shares used in the Traditional mode, directly increasing the early handshake payloads. This increase changes the lengths of packets carrying the ClientHello and ServerHello, as well as the total byte volume of the handshake. When the

6

omit content that appeared within the Non-PQC window. This constitutes a representation-level distribution shift rather than a change to the semantics of the encrypted application content. Taken together, Hybrid-PQC changes 𝐿 and 𝑃 directly through the expanded key_share values, while its effects on 𝐷 and 𝑇 arise through segmentation, scheduling, and implementation-dependent processing. This distinction links the protocol mechanisms described above to the testable hypotheses and feature-control experiments developed in the following sections.

IV. Building a PQC-Aware Encrypted Traffic Benchmark Section III showed how Hybrid-PQC key establishment can alter the observable traffic features used by encrypted traffic classifiers. To evaluate these effects empirically, we build a PQC-aware encrypted traffic benchmark in three stages. We first measure TLS key-establishment deployment across 2,060 Tranco-ranked websites. We then collect paired Non-PQC and Hybrid-PQC traffic for 195 common websites. Finally, we construct deployment-ratio test sets that vary the HybridPQC proportion while holding the label space and visit-level partitions fixed.

C. Hypotheses on Classifier Robustness under PQC-Induced Protocol Drift Building on the 4-tuple representation above, we formulate three testable hypotheses about the cross-domain robustness of encrypted traffic classifiers under PQC-induced protocol drift. Together, these hypotheses provide the analytical basis for the research questions examined later, linking protocol-level changes to classifier robustness during PQC migration.

A. Measuring TLS Key-Establishment Deployment To characterize TLS key-establishment deployment and identify candidate websites for paired traffic collection, we analyze 2,060 websites drawn from the Tranco ranking [20]. For each website, we record the negotiated TLS version and use Algorithm 1 to extract the distribution of key_share groups selected in ServerHello. The target SNI set includes both the base domain and its www-prefixed variant. Algorithm 1 processes each packet capture at the granularity of individual TLS sessions. It first identifies sessions containing both ClientHello and ServerHello. The client SNI is then compared with the target set, and each matching session contributes its ServerHello key_share group to the corresponding count. Separate counters record matched sessions without a key_share group, sessions with non-target SNIs, and incomplete handshakes. These counters retain the filtering outcomes needed to interpret the final group distribution. The resulting statistics characterize the key-establishment mechanisms observed for each website and guide the selection of websites used to construct the benchmark.

H1: Packet-Length Drift. Hybrid-PQC expands the KEM payloads carried during the TLS handshake, changing early packet lengths, positional offsets, and cumulative traffic profiles. The packet-length sequence 𝐿 and its derived statistics (e.g., cumulative curves and statistical moments) are primary inputs to encrypted traffic classifiers. We therefore hypothesize that models relying heavily on 𝐿 will exhibit substantial performance degradation when trained on Non-PQC traffic and evaluated on PQC traffic. H2: Directional and Temporal Drift. Hybrid-PQC may also alter the direction sequence 𝐷 and timing sequence 𝑇. Larger handshake messages can require additional TCP segments and, depending on preprocessing, change the positions of packets and acknowledgments within the first 𝑁 observations, thereby modifying uplink–downlink patterns. Hybrid-PQC introduces computational overhead from ML-KEM KeyGen, Encaps, and Decaps, as well as transmission overhead from serializing larger handshake messages. Together, these factors may alter packet inter-arrival time (IAT) distributions and handshake completion time. We therefore hypothesize that classifiers using temporal or combined direction–timing features will degrade across the Non-PQC and PQC domains, with larger effects on high-latency paths or resource-constrained endpoints.

1.3% 9.8% 38.6%

H3: Robustness of Pre-Trained Byte-Level Representations. Pre-trained traffic models such as ET-BERT and YaTC may partially reduce PQC-induced cross-domain degradation by capturing reusable byte-level structures in 𝑃. They may therefore be more robust than classifiers based primarily on 𝐿, 𝐷, and 𝑇, although fixed input windows and preprocessing choices constrain this advantage. ET-BERT’s input horizon may omit contextual bytes as handshake messages expand, whereas YaTC’s extraction window may capture shifted byte ranges when TLS-record boundaries change. If their pretraining corpora do not include Hybrid-PQC traffic, whether they can preserve their Non-PQC baseline performance remains uncertain.

50.3%

No Reply

TLS 1.2

TLS 1.3 Hybrid-PQC

TLS 1.3 Non-PQC

Fig. 4: Distribution of negotiated TLS versions and TLS 1.3 key-establishment modes across 2,060 Tranco-ranked websites. TLS 1.3 Non-PQC and Hybrid-PQC are identified by server-side key_share values of 29 (X25519) and 4588 (X25519MLKEM768), respectively.

7

Algorithm 1: Extraction of Negotiated TLS Key-Share Distributions

For each candidate website, we used Mozilla Firefox to automate full-page visits under two cryptographic configurations. We toggled the security.tls.enable_kyber preference to enable or disable Hybrid-PQC key establishment, thereby collecting Hybrid-PQC and Traditional (Non-PQC) traffic, respectively. We performed 120 complete page loads per website under each configuration to maintain balanced perwebsite sample counts across the two cryptographic domains. Each resulting packet trace corresponds to a single independent, isolated website visit. We reapplied Algorithm 1 to the collected packet captures and verified that all retained samples in the PQC Website Dataset negotiated X25519MLKEM768 (code point 4588), whereas all retained samples in the Non-PQC Website Dataset negotiated X25519 (code point 29). Dataset membership is therefore determined by the group selected in ServerHello, rather than by the intended browser configuration alone. From each validated packet capture, we extracted the TCP streams associated with the target SNIs to form the two benchmark datasets. Because a modern page load may span multiple TCP connections, we partition the data by complete website visit rather than by individual TCP stream. All streams extracted from the same visit are assigned to the same split, preventing related traffic from crossing the training, validation, and test partitions. Network and collection failures prevented four candidate websites from yielding valid captures under both configurations. We retained the remaining 195 websites as the shared label set for the two datasets and for the closed-world evaluation in Section V.

Input

: Packet-capture dataset dataset; target SNI set target_snis Output : Dictionary keyshare_stats Notations: ks_dist : keyshare_stats["key_share_groups"] matched : keyshare_stats["matched_count"] no_ks : keyshare_stats["no_key_share"] unmatched : keyshare_stats["sni_unmatched"] missing : keyshare_stats["missing_handshake"] 1 Initialize keyshare_stats; 2 for each capture file in dataset do 3 𝑠𝑒𝑠𝑠𝑖𝑜𝑛𝑠 ← Extract TLS sessions from capture file; 4 for each session in sessions do 5 ℎ𝑎𝑠 𝑐ℎ ← Check whether ClientHello exists; 6 ℎ𝑎𝑠 𝑠ℎ ← Check whether ServerHello exists; 7 if ℎ𝑎𝑠 𝑐ℎ and ℎ𝑎𝑠 𝑠ℎ then 8 𝑠𝑛𝑖 ← Extract server_name from ClientHello; 9 if 𝑠𝑛𝑖 ∈ target_snis then 10 matched ← matched + 1; 11 𝑘𝑠 ← Extract key_share group from ServerHello; 12 if 𝑘𝑠 is not NULL then 13 ks_dist[𝑘𝑠] += 1; 14 else 15 no_ks ← no_ks + 1; 16 end if 17 else 18 unmatched ← unmatched + 1; 19 end if 20 else 21 missing ← missing + 1; 22 end if 23 end for 24 end for 25 return keyshare_stats;

C. Constructing Deployment-Ratio Test Sets To model gradual Hybrid-PQC deployment, we construct four Mixed test sets from the paired test partitions of the Non-PQC Website Dataset and the PQC Website Dataset. Together with the Non-PQC and Hybrid-PQC endpoint test sets, they form six deployment-ratio settings. Let 𝛼 denote the proportion of Hybrid-PQC samples in a test set:

For TLS 1.3 connections, the group selected in ServerHello identifies the key-establishment mechanism used for that connection. Fig. 4 reports the observed TLS version and key-establishment distribution. Among the 2,060 websites, 50.3% negotiated Hybrid-PQC TLS 1.3 key establishment, while 38.6% negotiated Traditional (Non-PQC) TLS 1.3 key establishment. A further 9.8% used TLS 1.2, and 1.3% returned no reply. Hybrid-PQC was therefore the largest category in the measured sample and provided a sufficiently large candidate pool for the paired traffic collection described next.

𝛼=

𝑁Hybrid-PQC , 𝑁Non-PQC + 𝑁Hybrid-PQC

(3)

where 𝑁Hybrid-PQC and 𝑁Non-PQC denote the numbers of samples drawn from the corresponding cryptographic domains. We evaluate the following six settings:

B. Constructing Paired Non-PQC and Hybrid-PQC Traffic Datasets

𝛼 ∈ {0%, 20%, 40%, 60%, 80%, 100%}.

The deployment results obtained with Algorithm 1 and summarized in Fig. 4 show that the observed Hybrid-PQC TLS 1.3 connections selected the X25519MLKEM768 group. We therefore selected the Top 200 websites that support this group as candidates for paired traffic collection and used them to construct the Non-PQC Website Dataset and the PQC Website Dataset. Throughout this paper, the PQC Website Dataset refers specifically to traffic collected with Hybrid-PQC X25519MLKEM768 key establishment, rather than Pure-PQC key establishment.

(4)

The 0% and 100% settings correspond to the Non-PQC and Hybrid-PQC test sets, respectively, while the four intermediate values define the Mixed test sets. For each website, samples are selected according to 𝛼 and 1 − 𝛼. Applying the same value of 𝛼 to every website keeps the cryptographic composition uniform across all 195 labels and prevents class-dependent deployment skew from confounding classifier performance. The label space and visit-level partitioning remain fixed across the six settings, isolating the effect of changes in the test-domain composition.

8

TABLE III: Overview of the encrypted traffic classifiers evaluated under PQC-induced protocol drift. Classifier

Learning Method

Native Input

Evaluation Role

CUMUL

SVM with hand-crafted features

Statistical features and a sampled cumulative traffic curve

Sensitivity to aggregate traffic volume and cumulative transfer profiles

DF

One-dimensional convolutional network

Direction-coded packet sequence

Sensitivity to local sequence patterns and positional alignment

Tik-Tok

Deep sequence model with timing

Packet length, direction, and inter-arrival time (IAT)

Sensitivity to joint sequence and timing changes

ET-BERT

Pre-trained Transformer

Anonymized datagram bytes (first five packets; 128 bytes per packet)

Transfer of contextualized datagram representations

YaTC

Pre-trained masked autoencoder

Anonymized multi-level flow representation (first five packets; 80-byte header + 240-byte payload per packet)

Transfer of multi-level flow representations

These test sets support the deployment-ratio and feature-control experiments in RQ3 and RQ4.

models. This grouping reflects both the information available to each classifier and the strategy used to construct or learn its representation. Together, the models cover the packet-length, direction, timing, and byte-level dimensions, 𝐿, 𝐷, 𝑇, and 𝑃, introduced in Section III, while preserving their distinct native inputs. CUMUL combines summary statistics with a sampled cumulative traffic curve, providing an aggregate view of transferred volume and its progression throughout a trace. It is therefore sensitive to changes in total traffic volume and cumulative transfer profiles. DF applies one-dimensional convolutions to direction-coded packet sequences and learns local patterns from their ordering and positional alignment. These patterns may shift if larger Hybrid-PQC key shares alter TCP segmentation and packet positions. Tik-Tok incorporates packet timing alongside length and direction, enabling the joint modeling of packet sequences and inter-arrival time (IAT). It provides a timingaware view of changes arising from serialization, segmentation, and implementation-dependent processing. By comparison, ETBERT pre-trains a Transformer over contextualized datagram representations. YaTC uses masked autoencoding to learn a multi-level flow representation. Their anonymized byte-oriented inputs represent 𝑃 and may be sensitive to shifted byte offsets and fixed observation windows. The five-model set therefore compares explicit side-channel representations with reusable byte-level representations across the Non-PQC and Hybrid-PQC domains, without presuming that pre-training provides crossdomain robustness. 2) Evaluation Controls: All five classifiers are evaluated on the same closed-world HTTPS website fingerprinting task over a shared label set of 195 websites. For each website and cryptographic domain, the evaluation draws 120 complete visits collected in Section IV. These visits are partitioned at the granularity of complete website visits, each of which may contain multiple TCP streams. All models use identical partition assignments, with 80, 10, and 10 ratio per website allocated to the training, validation, and test sets, respectively. Because the classifiers expose different input modalities by design, we preserve each model’s native feature extraction and

V. Evaluation Building on the PQC-aware encrypted traffic benchmark developed in Section IV, this section evaluates the reliability of representative encrypted traffic classifiers under PQCinduced protocol drift across matched-domain, cross-domain, deployment-ratio, and feature-controlled settings. A. Threat Model and Evaluation Scope We consider a passive network adversary positioned near the client. The adversary observes the encrypted packet trace associated with a complete, isolated website visit over HTTPS, but cannot decrypt, modify, or inject traffic. Its objective is to infer the visited domain from the shared set of 195 Tranco websites under a closed-world setting. Holding the label space and browsing procedure fixed isolates the effect of the transition from Non-PQC to Hybrid-PQC key establishment on classifier reliability. To compare the five representative classifiers without altering their native assumptions, we preserve each model’s feature representation and preprocessing workflow. Inputs are restricted to information available in passively observed packets. Outof-band DNS traffic and decrypted information from the TLS handshake or application layer, including certificate contents, HTTP Host headers, and URLs, are excluded from every classifier. The scope further excludes Tor and VPN tunneling, active attacks such as probing or traffic injection, and openworld evaluation. The experiments, therefore, assess classifier reliability under controlled PQC-induced protocol drift rather than attack effectiveness in unconstrained Internet deployments. B. Experimental Setup 1) Evaluated Classifiers: To examine PQC-induced protocol drift across distinct observation surfaces and learning paradigms, we select five representative classifiers for encrypted traffic. Table III organizes them into three groups consistent with the taxonomy in Section II: an aggregate statistical method, two packet-sequence models, and two pre-trained byte-level

9

TABLE IV: Matched-domain performance of the evaluated classifiers under the N-N and P-P settings.

preprocessing instead of imposing a common representation. For RQ1–RQ3, CUMUL, DF, and Tik-Tok retain their native statistical or packet-sequence inputs. ET-BERT and YaTC retain their model-specific sanitization, tokenization, truncation, and representation construction. RQ4 deliberately varies only the input representation of DF while holding its architecture and training procedure fixed. Given the remaining input heterogeneity, we compare each classifier primarily against its own matched-domain baseline and avoid attributing absolute cross-model rankings solely to model architecture. We report accuracy, precision, recall, and F1 score for every evaluation setting. 3) Research Questions: To structure the evaluation of classifier reliability under PQC-induced protocol drift, we formulate four research questions.

Classifier

Accuracy

Precision

N-N

N-N

P-P

P-P

Recall N-N

P-P

F1 score N-N

P-P

CUMUL 0.7731 0.7656 0.7925 0.7731 0.7731 0.7662 0.7598 0.7538 DF 0.5855 0.5900 0.5792 0.5942 0.5855 0.5904 0.5500 0.5615 Tik-Tok 0.5679 0.5737 0.5640 0.5594 0.5679 0.5739 0.5319 0.5397 ET-BERT 0.9316 0.9332 0.9059 0.9076 0.9316 0.9333 0.9138 0.9157 YaTC 1.0000 0.9991 1.0000 0.9993 1.0000 0.9991 1.0000 0.9991

DF achieves accuracies of 0.5855 and 0.5900, with F1 scores of 0.5500 and 0.5615, under N-N and P-P, respectively. The corresponding values for Tik-Tok are 0.5679 and 0.5737 for accuracy and 0.5319 and 0.5397 for F1 score. Within their native preprocessing pipelines, the pre-trained byte-level models attain the highest matched-domain scores. ET-BERT records accuracies of 0.9316 and 0.9332 and F1 scores of 0.9138 and 0.9157. YaTC remains near perfect, with accuracy decreasing only from 1.0000 to 0.9991 and F1 score from 1.0000 to 0.9991. Precision and recall follow the same overall pattern. Across all four metrics, the N-N and P-P results remain close for every classifier. These matched-domain results provide the baselines for the cross-domain transfer analysis in RQ2.

Research Questions RQ1: (Matched-Domain Learnability) How does Hybrid-PQC key establishment affect website fingerprinting performance when training and testing use the same cryptographic domain? RQ2: (Bidirectional Cross-Domain Transfer) How well do classifiers transfer between Non-PQC and Hybrid-PQC traffic domains?

Answer to RQ1: Hybrid-PQC key establishment does not produce a consistent loss of matched-domain learnability in our evaluation. All five classifiers achieve comparable N-N and P-P performance when trained and tested within a single cryptographic domain, indicating that Hybrid-PQC traffic retains learnable website fingerprints.

RQ3: (Deployment-Ratio Sensitivity) How does classifier performance change as the proportion of Hybrid-PQC traffic increases across the deployment-ratio settings? RQ4: (Side-Channel Feature Contributions) How do packet length, direction, and timing, individually and jointly, affect website fingerprinting performance under PQC-induced protocol drift?

D. RQ2: Bidirectional Cross-Domain Transfer RQ2 evaluates whether classifiers trained in one cryptographic domain transfer to the other without retraining. The N-P setting models an adversary whose classifier was trained on Non-PQC traffic but is applied after Hybrid-PQC deployment. For each of the 195 websites, every classifier is trained on 80 visits and tuned on 10 validation visits from the Non-PQC Website Dataset. The resulting model is then evaluated on 10 held-out visits from the PQC Website Dataset. The P-N setting reverses the source and target domains to assess whether cross-domain transfer depends on direction. Each classifier is trained on 80 visits and tuned on 10 validation visits per website from the PQC Website Dataset. It is then evaluated on 10 held-out visits from the Non-PQC Website Dataset. Both settings use the same website labels, visitlevel partitions, and model configurations as RQ1. Table V reports the results. N-P denotes training or fine-tuning on NonPQC traffic and testing on Hybrid-PQC traffic. P-N denotes the reverse direction. This bidirectional design distinguishes forward transfer to Hybrid-PQC traffic from backward transfer to Non-PQC traffic. Relative to the matched-domain baselines in Table IV, Table V shows lower cross-domain performance for every

C. RQ1: Matched-Domain Learnability RQ1 examines whether website identity remains learnable after Hybrid-PQC key establishment when training and testing are matched within the same cryptographic domain. We train, validate, and test all five classifiers separately on the NonPQC Website Dataset and the PQC Website Dataset. Both settings retain the same 195 website labels, visit-level partitions, and model configurations. The PQC Website Dataset contains Hybrid-PQC traffic negotiated with X25519MLKEM768. This matched-domain design tests whether each domain supports website fingerprinting without introducing the distribution mismatch examined in RQ2. Table IV reports the results. NN denotes training or fine-tuning and testing on the Non-PQC Website Dataset. P-P denotes the corresponding procedure on the PQC Website Dataset. Table IV shows that each classifier attains similar N-N and P-P performance, although absolute performance differs substantially across classifiers. The aggregate-statistical CUMUL classifier records accuracies of 0.7731 and 0.7656, with F1 scores of 0.7598 and 0.7538. The packet-sequence models likewise show only small differences between the two domains.

10

TABLE V: Bidirectional cross-domain performance of the evaluated classifiers under the N-P and P-N settings. Classifier

Accuracy

Precision

N-P

N-P

P-N

P-N

Recall N-P

P-N

The four Mixed test settings, N-M2, N-M4, N-M6, and N-M8, correspond to 𝛼 = 20%, 40%, 60%, and 80%. This design isolates sensitivity to deployment composition while keeping the training domain fixed. Fig. 5 shows that every classifier has lower accuracy under N-P than under N-N, although their intermediate trajectories differ. CUMUL declines monotonically from 0.7731 to 0.1919. The packet-sequence models follow shallower but similarly monotonic declines: DF decreases from 0.5855 to 0.3728, while Tik-Tok decreases from 0.5679 to 0.3873. These three classifiers therefore deteriorate progressively as the test distribution moves away from the Non-PQC training domain.

F1 score N-P

P-N

CUMUL 0.1919 0.2778 0.2135 0.2559 0.1928 0.2778 0.1765 0.2394 DF 0.3728 0.4923 0.3678 0.4800 0.3742 0.4923 0.3487 0.4609 Tik-Tok 0.3873 0.4256 0.3971 0.4321 0.3880 0.4256 0.3627 0.4079 ET-BERT 0.6255 0.6043 0.5208 0.5073 0.6256 0.6043 0.5476 0.5291 YaTC 0.3582 0.9709 0.3225 0.9614 0.3585 0.9709 0.2835 0.9634

classifier. The magnitude of degradation, however, varies by classifier and transfer direction. Under N-P, CUMUL, DF, and Tik-Tok achieve accuracies of 0.1919, 0.3728, and 0.3873, respectively. These values are below their N-N accuracies of 0.7731, 0.5855, and 0.5679. YaTC declines from an NN accuracy of 1.0000 to 0.3582, with an N-P F1 score of 0.2835. ET-BERT retains the highest N-P accuracy at 0.6255 but remains below its N-N accuracy of 0.9316, and its N-P F1 score is 0.5476. Strong matched-domain performance therefore does not predict transfer from Non-PQC to Hybrid-PQC traffic. The P-N results reveal substantial directional asymmetry. YaTC retains an accuracy of 0.9709 and an F1 score of 0.9634, close to its P-P accuracy and F1 score of 0.9991. By contrast, ET-BERT records an accuracy of 0.6043 and an F1 score of 0.5291. CUMUL, DF, and Tik-Tok remain below 0.5000 accuracy at 0.2778, 0.4923, and 0.4256, respectively. Four classifiers perform better in P-N than in N-P, whereas ETBERT is the exception. Thus, only YaTC approaches matcheddomain performance in the reverse direction. The experiment establishes asymmetric transfer, but it does not by itself identify the mechanism underlying YaTC’s P-N behavior.

Fig. 5: Accuracy trajectories of the five evaluated classifiers trained exclusively on Non-PQC traffic across six test settings as the Hybrid-PQC proportion increases from 0% to 100%. The two pre-trained byte-oriented models exhibit different responses to the changing traffic mixture:

Answer to RQ2: Cross-domain transfer is generally weaker than matched-domain performance and strongly depends on the direction. All five classifiers degrade outside their training domain. Only YaTC approaches its matched-domain baseline in P-N, while degrading substantially in N-P. High matched-domain accuracy therefore does not ensure reliability under PQC-induced protocol drift. Models should be re-evaluated and, where necessary, retrained or adapted when the cryptographic domain changes.

• YaTC achieves an accuracy of 1.0000 under N-N, drops

to 0.6166 at N-M4, and partially recovers to 0.7252 at N-M8. Its accuracy then falls to 0.3582 under N-P. This non-monotonic trajectory shows that an intermediate traffic mixture does not necessarily produce intermediate performance. • ET-BERT declines monotonically from 0.9316 under NN to 0.6255 under N-P. It records the highest accuracy at N-M2, N-M4, N-M6, and N-P, whereas YaTC exceeds it at N-M8. ET-BERT thus exhibits the most consistent performance across the evaluated ratios, although its endpoint remains below its Non-PQC baseline.

E. RQ3: Deployment-Ratio Sensitivity RQ3 examines how classifiers trained or fine-tuned exclusively on Non-PQC traffic behave as the proportion of HybridPQC traffic increases in the test distribution. Each of the five classifiers uses the training and validation partitions of the Non-PQC Website Dataset and is then evaluated, without retraining or further fine-tuning, under the six deployment-ratio settings defined in Section IV. Their Hybrid-PQC proportions are 𝛼 ∈ {0%, 20%, 40%, 60%, 80%, 100%}. All settings retain the same 195 website labels and visit-level partitions. Here, N-N and N-P denote testing at 𝛼 = 0% and 𝛼 = 100%, respectively.

Answer to RQ3: Across all five classifiers, increasing the Hybrid-PQC proportion generally reduces accuracy relative to the Non-PQC baseline, although the trajectories differ. CUMUL, DF, Tik-Tok, and ET-BERT decline monotonically, whereas YaTC changes nonmonotonically. No classifier preserves its Non-PQC baseline across the full deployment range.

11

F. RQ4: Side-Channel Feature Contributions RQ4 isolates the individual and joint contributions of packet direction, packet length, and timing under PQC-induced protocol drift. We use DF as the controlled architecture and vary only its input representation. The D configuration retains the native direction-coded input of DF and serves as the baseline. We compare it with four additional configurations: (1) L, using only absolute packet lengths; (2) T, using only normalized interarrival times (IATs); (3) DL, combining aligned direction and length sequences; and (4) DLT, combining direction, length, and IAT. All five configurations use the same model architecture, training procedure, Non-PQC training and validation partitions, and six deployment-ratio settings defined in Section IV and used in RQ3. This controlled design attributes differences in classification performance to input composition rather than model architecture or dataset partitioning.

achieve accuracies of 0.8026 and 0.7983, only slightly above the 0.7944 achieved by L. The corresponding values under NM2 are 0.7272, 0.7241, and 0.7205. From N-M4 onward, length alone outperforms both combined representations. Under N-P, L achieves 0.4310, compared with 0.4186 for DL and 0.3899 for DLT. Moreover, DLT never surpasses DL, indicating that adding timing to the direction–length representation provides no benefit in any evaluated setting. Neither direction nor timing compensates for the loss associated with PQC-induced protocol drift. Answer to RQ4: Packet length provides the strongest individual side-channel signal across all deployment ratios, although its advantage diminishes as the HybridPQC proportion increases. Direction offers no consistent benefit when combined with length, and adding timing to the direction–length representation does not improve accuracy. All five representations degrade under PQCinduced protocol drift, indicating that feature fusion alone does not provide cross-domain robustness. VI. Discussion A. Beyond Hybrid Key Establishment: Post-Quantum Authentication Our empirical evaluation isolates PQC-induced drift at key establishment. It covers Hybrid-PQC negotiation with X25519MLKEM768, while Pure-PQC key establishment appears only as a protocol-level comparison in Section III. A broader migration would also introduce post-quantum signatures and certificate chains into TLS authentication. ML-DSA and Falcon can add kilobyte-scale authentication material, altering packetization, burst boundaries, and handshake timing. These effects are not uniform increases in flow size. Crossing TLS-record or TCP-segmentation thresholds can insert or reposition packets, producing discontinuities in classifier inputs. Post-quantum authentication may therefore reinforce or partially mask the drift introduced by key establishment, depending on certificate-chain composition and implementation behavior. A factorial evaluation that varies the KEM and authentication mechanism independently would separate these effects and reveal whether classifiers learn application-level invariants or migration-specific artifacts.

Fig. 6: Accuracy trajectories of DF with five individual and combined side-channel representations (D, L, T, DL, and DLT) as the Hybrid-PQC proportion increases from 0% to 100%. Fig. 6 shows a monotonic decline in accuracy from N-N to NP for all five input representations. Among the single-channel configurations, D decreases from 0.5855 to 0.3728, L from 0.7944 to 0.4310, and T from 0.5560 to 0.3766. The combined representations follow the same pattern: DL decreases from 0.8026 to 0.4186, while DLT decreases from 0.7983 to 0.3899. Thus, changing the feature composition alters the attainable accuracy but does not prevent degradation as the test distribution moves away from the Non-PQC training domain. The per-setting comparisons in Fig. 7 identify packet length as the strongest individual feature throughout the deployment range. Under N-N, L achieves an accuracy of 0.7944, compared with 0.5855 for D and 0.5560 for T. This ordering persists across all four Mixed test sets. Under N-P, L retains an accuracy of 0.4310, whereas D and T achieve 0.3728 and 0.3766, respectively. However, the advantage of L over D narrows from 0.2089 under N-N to 0.0582 under N-P; its advantage over T similarly narrows from 0.2384 to 0.0544. Packet length therefore remains the most discriminative individual feature, although PQC-induced protocol drift progressively erodes its advantage. Feature combination provides only marginal gains when the Hybrid-PQC proportion is low. Under N-N, DL and DLT

B. Practical Trade-offs of LLM-Based Traffic Classifiers Model scale does not by itself address the failure mode identified in our evaluation. The results for ET-BERT and YaTC show that high matched-domain accuracy and crossdomain robustness can diverge substantially. An LLM-based classifier may capture longer byte-level dependencies and richer contextual relationships, but the same capacity may strengthen its reliance on protocol-specific shortcuts. The relevant question is whether these representations remain stable across cryptographic environments, not whether they improve matcheddomain accuracy.

12

Fig. 7: Per-setting accuracy of DF with five side-channel representations across six Hybrid-PQC deployment ratios, covering the Non-PQC, Mixed, and Hybrid-PQC test sets.

For a fair comparison, tokenization, pre-training corpora, input truncation, and adaptation data should be treated as part of the classifier rather than as implementation details. Evaluation should report bidirectional transfer, the data and computation required to recover from drift, and operational costs such as throughput, latency, and memory. In this setting, a larger model is practically meaningful only if it improves the robustnesscost trade-off, rather than merely recovering matched-domain accuracy through greater capacity.

VII. Conclusion This work evaluates the reliability of encrypted traffic classifiers under PQC-induced protocol drift, focusing on the practically deployed Hybrid-PQC X25519MLKEM768 group in TLS 1.3. Across five representative classifiers, matched-domain experiments show that Hybrid-PQC traffic retains learnable website identity features when training and testing use the same cryptographic environment. However, models trained on Non-PQC traffic degrade when evaluated on Hybrid-PQC traffic, and their accuracy generally declines as the HybridPQC proportion increases in Mixed test sets. The asymmetric transfer behavior of individual models further shows that strong in-domain performance does not predict stability across cryptographic environments. Our feature analysis identifies packet length as the dominant side channel, while direction and timing provide limited additional benefit in the evaluated configurations. Taken together, these findings characterize PQC evolution as a source of model mismatch rather than a permanent obstacle to encrypted traffic classification. The results have two implications for evaluating encrypted traffic classifiers. First, protocol configurations should be treated as explicit evaluation dimensions rather than hidden dataset properties. Matched-domain accuracy should therefore be accompanied by cross-domain tests that expose sensitivity to protocol evolution. Second, datasets should reflect contemporary cryptographic deployments. The observed behavior may differ under other protocol stacks, cryptographic configurations, or attack settings not examined in this work. More broadly, reliable encrypted traffic classification requires evidence that representations transfer across evolving protocol environments, not merely that they perform well under matched conditions.

C. PQC-Induced Protocol Drift as Incidental Obfuscation The distinction between in-domain learnability and crossdomain degradation changes how PQC’s apparent obfuscation should be interpreted. Hybrid-PQC traffic remains distinguishable after in-domain training, whereas Non-PQC-trained models degrade under the shifted distribution. Any apparent protection therefore reflects model staleness rather than removal of websitedependent information. Feature ablation further identifies packet length as the dominant discriminative signal, consistent with drift in message size and packetization. Deterministic cryptographic expansion is unlikely to provide durable obfuscation once its patterns enter an attacker’s training data. Protocol migration nevertheless exposes a useful defensive principle: shifting traffic beyond the training distribution can impose an adaptation cost while perturbations remain difficult to model or relearn. Our closed-world evaluation of X25519MLKEM768 cannot establish this cost for other stacks or attack settings. Accordingly, defenses inspired by PQC-induced drift should be evaluated against adaptive traffic recollection and model retraining, not only fixed legacy classifiers.

13

[20] V. Le Pochat, T. Van Goethem, S. Tajalizadehkhoob, W. Joosen et al., “Tranco: A research-oriented top sites ranking hardened against manipulation,” in Proceedings of the 26th Annual Network and Distributed System Security Symposium, 2019, pp. 1–15. [21] F. Driscoll, M. Parsons, and B. Hale, “Terminology for post-quantum traditional hybrid schemes,” Internet Engineering Task Force, RFC 9794, Jun. 2025. [Online]. Available: https://www.rfc-editor.org/info/rfc9794 [22] R. L. Rivest, A. Shamir, and L. Adleman, “A method for obtaining digital signatures and public-key cryptosystems,” Communications of the ACM, vol. 21, no. 2, pp. 120–126, 1978. [23] N. Koblitz, “Elliptic curve cryptosystems,” Mathematics of Computation, vol. 48, no. 177, pp. 203–209, 1987. [24] P. W. Shor, “Algorithms for quantum computation: Discrete logarithms and factoring,” in Proceedings of the 35th Annual Symposium on Foundations of Computer Science, 1994, pp. 124–134. [25] National Institute of Standards and Technology, “Stateless hash-based digital signature standard,” National Institute of Standards and Technology, Federal Information Processing Standards Publication FIPS 205, Aug. 2024. [Online]. Available: https://csrc.nist.gov/pubs/fips/205/final [26] J. Bos, L. Ducas, E. Kiltz, T. Lepoint, V. Lyubashevsky, J. M. Schanck, P. Schwabe, G. Seiler, and D. Stehlé, “CRYSTALS-Kyber: A CCA-secure module-lattice-based KEM,” in 2018 IEEE European Symposium on Security and Privacy (EuroS&P), 2018, pp. 353–367. [27] B. Westerbaan, “State of the post-quantum internet in 2025,” Cloudflare Blog, Oct. 2025. [Online]. Available: https://blog.cloudflare.com/ pq-2025/ [28] K. Kwiatkowski, P. Kampanakis, B. Westerbaan, and D. Stebila, “Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3,” Internet Engineering Task Force, Internet-Draft draft-ietf-tls-ecdhemlkem-05, May 2026, work in Progress. [Online]. Available: https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/05/ [29] D. Connolly, “ML-KEM Post-Quantum Key Agreement for TLS 1.3,” Internet Engineering Task Force, Internet-Draft draft-ietftls-mlkem-09, Jul. 2026, work in Progress. [Online]. Available: https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/09/ [30] Y. Qing, Q. Yin, X. Deng, X. Zhang, P. Li, Z. Liu, K. Sun, K. Xu, and Q. Li, “Training robust classifiers for classifying encrypted traffic under dynamic network conditions,” in Proceedings of the 2025 ACM SIGSAC Conference on Computer and Communications Security, 2025, pp. 3564– 3578. [31] X. Deng, Y. Zhang, Q. Li, Z. Liu, Y. Wang, and K. Xu, “Enhancing website fingerprinting attacks against traffic drift,” in 33rd Annual Network and Distributed System Security Symposium, NDSS 2026, 2026. [32] M. Shen, K. Ye, X. Liu, L. Zhu, J. Kang, S. Yu, Q. Li, and K. Xu, “Machine learning-powered encrypted network traffic analysis: A comprehensive survey,” IEEE Communications Surveys & Tutorials, vol. 25, no. 1, pp. 791–824, 2023. [33] T. T. T. Nguyen and G. Armitage, “A survey of techniques for internet traffic classification using machine learning,” IEEE Communications Surveys & Tutorials, vol. 10, no. 4, pp. 56–76, 2008. [34] J. Hayes and G. Danezis, “k-fingerprinting: A robust scalable website fingerprinting technique,” in 25th USENIX Security Symposium (USENIX Security 16), 2016, pp. 1187–1203. [35] T. Van Ede, R. Bortolameotti, A. Continella, J. Ren, D. J. Dubois, M. Lindorfer, D. Choffnes, M. Van Steen, and A. Peter, “Flowprint: Semisupervised mobile-app fingerprinting on encrypted network traffic,” in Network and distributed system security symposium (NDSS), vol. 27, 2020. [36] I. A. Najm, A. H. Saeed, B. Ahmad, S. R. Ahmed, R. Sekhar, P. Shah, and B. Veena, “Enhanced network traffic classification with machine learning algorithms,” in Proceedings of the cognitive models and artificial intelligence conference, 2024, pp. 322–327. [37] C. Liu, L. He, G. Xiong, Z. Cao, and Z. Li, “FS-Net: A flow sequence network for encrypted traffic classification,” in IEEE Conference on Computer Communications, 2019, pp. 1171–1179. [38] T. Shapira and Y. Shavitt, “FlowPic: A generic representation for encrypted traffic classification and applications identification,” IEEE Transactions on Network and Service Management, vol. 18, no. 2, pp. 1218–1232, 2021. [39] M. Shen, J. Zhang, L. Zhu, K. Xu, and X. Du, “Accurate decentralized application identification via encrypted traffic analysis using graph neural networks,” IEEE Transactions on Information Forensics and Security, vol. 16, pp. 2367–2380, 2021.

References [1] N. Wickramasinghe, A. Shaghaghi, G. Tsudik, and S. Jha, “SoK: Decoding the enigma of encrypted network traffic classifiers,” in 2025 IEEE Symposium on Security and Privacy (SP), 2025, pp. 1825–1843. [2] Y. Zhao, G. Dettori, M. Boffa, L. Vassio, and M. Mellia, “The sweet danger of sugar: Debunking representation learning for encrypted traffic classification,” in Proceedings of the ACM SIGCOMM 2025 Conference, 2025, pp. 296–310. [3] E. Akbari, Z. Zhou, M. A. Salahuddin, N. Limam, R. Boutaba, B. Mathieu, S. Moteau, and S. Tuffin, “One task to rule them all: A closer look at traffic classification generalizability,” 2025. [Online]. Available: https://arxiv.org/abs/2507.06430 [4] Y. Cheng, Y. Zhu, B. Li, P. Sun, Y. Ding, X. Deng, and Q. Liu, “HOLMES & WATSON: A robust and lightweight HTTPS website fingerprinting through HTTP version parallelism,” in Proceedings of the ACM Web Conference 2025, 2025, pp. 1078–1092. [5] Y. Cheng, Y. Zhu, B. Li, X. Deng, Y. Cai, Y. Ren, and Q. Liu, “Star: Semantic-traffic alignment and retrieval for zero-shot https website fingerprinting,” in IEEE INFOCOM 2026-IEEE Conference on Computer Communications, 2026, pp. 1–10. [6] A. Panchenko, F. Lanze, J. Pennekamp, T. Engel, A. Zinnen, M. Henze, and K. Wehrle, “Website fingerprinting at internet scale.” in NDSS, vol. 1, 2016, p. 23477. [7] P. Sirinam, M. Imani, M. Juarez, and M. Wright, “Deep fingerprinting: Undermining website fingerprinting defenses with deep learning,” in Proceedings of the 2018 ACM SIGSAC conference on computer and communications security, 2018, pp. 1928–1943. [8] M. S. Rahman, P. Sirinam, N. Mathews, K. G. Gangadhara, and M. Wright, “Tik-Tok : The utility of packet timing in website fingerprinting attacks,” Proceedings on Privacy Enhancing Technologies, vol. 2020, no. 3, pp. 5–24, Jul. 2020. [9] X. Lin, G. Xiong, G. Gou, Z. Li, J. Shi, and J. Yu, “ET-BERT: A contextualized datagram representation with pre-training transformers for encrypted traffic classification,” in Proceedings of the ACM Web Conference 2022, 2022, pp. 633–642. [10] R. Zhao, M. Zhan, X. Deng, Y. Wang, Y. Wang, G. Gui, and Z. Xue, “Yet another traffic classifier: A masked autoencoder based traffic transformer with multi-level flow representation,” Proceedings of the AAAI Conference on Artificial Intelligence, vol. 37, no. 4, pp. 5420–5427, Jun. 2023. [11] National Institute of Standards and Technology, “Module-latticebased key-encapsulation mechanism standard,” National Institute of Standards and Technology, Federal Information Processing Standards Publication FIPS 203, Aug. 2024. [Online]. Available: https://csrc.nist.gov/pubs/fips/203/final [12] G. Alagic, E. Barker, L. Chen, D. Moody, A. Robinson, H. Silberg, and N. Waller, “Recommendations for Key-Encapsulation Mechanisms,” National Institute of Standards and Technology, Tech. Rep. NIST Special Publication (SP) 800-227, Sep. 2025. [13] D. Stebila, S. Fluhrer, and S. Gueron, “Hybrid Key Exchange in TLS 1.3,” Internet Engineering Task Force, RFC 9954, Jul. 2026. [Online]. Available: https://www.rfc-editor.org/info/rfc9954 [14] E. Rescorla, “The transport layer security (tls) protocol version 1.3,” Internet Engineering Task Force, RFC 9846, Jul. 2026. [Online]. Available: https://www.rfc-editor.org/info/rfc9846 [15] J. A. Montenegro, R. Rios, and J. Lopez-Cerezo, “A performance evaluation framework for post-quantum tls,” Future Generation Computer Systems, vol. 175, p. 108062, 2026. [16] J. Iyengar and M. Thomson, “Quic: A udp-based multiplexed and secure transport,” Internet Engineering Task Force, RFC 9000, May 2021. [Online]. Available: https://www.rfc-editor.org/info/rfc9000 [17] H. F. Alan and J. Kaur, “Client diversity factor in HTTPS webpage fingerprinting,” in Proceedings of the Ninth ACM Conference on Data and Application Security and Privacy, 2019, pp. 279–290. [18] Z. Chen, G. Cheng, J. Li, T. Qin, Y. Zhou, and X. Luan, “Drift-oriented self-evolving encrypted traffic application classification for actual network environment,” 2025. [Online]. Available: https: //arxiv.org/abs/2501.04246 [19] National Institute of Standards and Technology, “Module-lattice-based digital signature standard,” National Institute of Standards and Technology, Federal Information Processing Standards Publication FIPS 204, Aug. 2024. [Online]. Available: https://csrc.nist.gov/pubs/fips/204/final

14

[40] Y. Liu, X. Wang, B. Qu, and F. Zhao, “Atvitsc: A novel encrypted traffic classification method based on deep learning,” IEEE transactions on information forensics and security, vol. 19, pp. 9374–9389, 2024. [41] H. Zhang, L. Yu, X. Xiao, Q. Li, F. Mercaldo, X. Luo, and Q. Liu, “Tfe-gnn: A temporal fusion encoder using graph neural networks for fine-grained encrypted traffic classification,” in Proceedings of the ACM web conference 2023, 2023, pp. 2066–2075. [42] W. Wang, M. Zhu, X. Zeng, X. Ye, and Y. Sheng, “Malware traffic classification using convolutional neural network for representation learning,” in 2017 International Conference on Information Networking (ICOIN), 2017, pp. 712–717. [43] W. Peng, L. Cui, W. Cai, W. Wang, X. Cui, Z. Hao, and X. Yun, “Bottom aggregating, top separating: An aggregator and separator network for encrypted traffic understanding,” IEEE Transactions on Information Forensics and Security, vol. 20, pp. 1794–1806, 2025. [44] T. Wang, X. Xie, W. Wang, C. Wang, Y. Zhao, and Y. Cui, “Netmamba: Efficient network traffic classification via pre-training unidirectional mamba,” in 2024 IEEE 32nd International Conference on Network Protocols (ICNP), 2024, pp. 1–11. [45] G. Zhou, X. Guo, Z. Liu, T. Li, Q. Li, and K. Xu, “TrafficFormer: An efficient pre-trained model for traffic data,” in IEEE Symposium on Security and Privacy (SP), 2025, pp. 1844–1860. [46] T. Cui, X. Lin, S. Li, M. Chen, Q. Yin, Q. Li, and K. Xu, “Trafficllm: Enhancing large language models for network traffic analysis with generic traffic representation,” 2025. [Online]. Available: https://arxiv.org/abs/2504.04222 [47] Y. Ginige, T. Dahanayaka, and S. Seneviratne, “TrafficGPT: An LLM approach for open-set encrypted traffic classification,” in Proceedings of the 19th Asian Internet Engineering Conference, 2024, pp. 26–35. [48] X. Zhao, X. Deng, T. Cui, Y. Zhang, K. Xu, and Q. Li, “Robust llmbased website fingerprinting under dynamic real-world conditions,” in Proceedings of the ACM Web Conference 2026, 2026, pp. 2800–2811. [49] C. Fan, W. Wang, W. Huang, Z. Ding, J. Shi, L. Cui, Z. Hao, and X. Yun, “ResAware: Cross-environment website fingerprinting via resource-privileged distillation,” 2026. [Online]. Available: https://arxiv.org/abs/2606.17462 [50] M. Shadbeh, K. Khajavi, and T. Wang, “Reality check for Tor website fingerprinting in the open world,” 2026. [Online]. Available: https://arxiv.org/abs/2603.07412 [51] Y. Yuan, Y. Huang, X. Zeng, H. Mei, and G. Cheng, “M3S-UPD: Efficient multi-stage self-supervised learning for fine-grained encrypted traffic classification with unknown pattern discovery,” 2025. [Online]. Available: https://arxiv.org/abs/2505.21462 [52] Y. Xian, X. Zeng, A. Zhou, J. Shi, Z. Hao, L. Cui, and P. Liu, “UDFS: Lightweight representation-driven open world robust encrypted traffic classification,” 2025. [Online]. Available: https://arxiv.org/abs/2509.11157 [53] D. Soukup, R. Plný, D. Vašata, and T. Čejka, “Drift-based dataset stability benchmark,” 2025. [Online]. Available: https://arxiv.org/abs/2512.23762 [54] Q. Zhang and C.-J. Su, “Application-layer characterization and traffic analysis for encrypted quic transport protocol,” in 2023 IEEE Conference on Communications and Network Security (CNS), 2023, pp. 1–9. [55] D. Gómez-Cambronero, D. Munteanu, and A. I. González-Tablas, “Layered performance analysis of TLS 1.3 handshakes: Classical, hybrid, and pure post-quantum key exchange,” 2026. [Online]. Available: https://arxiv.org/abs/2603.11006 [56] T. Mallick, C. Nita-Rotaru, A. Kundu, and R. Kompella, “Classifying implementations of cryptographic primitives and protocols that use post-quantum algorithms,” 2025. [Online]. Available: https: //arxiv.org/abs/2503.17830 [57] E. Rescorla, K. Oku, N. Sullivan, and C. A. Wood, “TLS Encrypted Client Hello,” Internet Engineering Task Force, RFC 9849, Mar. 2026. [Online]. Available: https://www.rfc-editor.org/info/rfc9849 [58] H. Krawczyk and P. Eronen, “HMAC-based Extract-and-Expand Key Derivation Function (HKDF),” Internet Engineering Task Force, RFC 5869, May 2010. [Online]. Available: https://www.rfc-editor.org/info/ rfc5869

15

Related documents

• Curv-Tail: Lightweight Long-Tailed Encrypted Traffic Classification with Discrete Packet-Length Encoding and Lorentz Prototypes#1116573
• Adversarial Robustness of Traffic Classification under Resource Constraints: Input Structure Matters#923120
• Problem Definition and Classification of BGP Route Leaks#166261
• Discard the Dross and Select the Essential: Pre-query Sample Selection for Black-box Membership Inference Attacks#321749
• Deep learning-based multi-class misbehavior classification in fog-enabled vehicular ad hoc networks.#666113