Study of Post Quantum status of Widely Used Protocols

Study of Post antum status of Widely Used Protocols T ushin Mallick ∗ Cisco Research Ashish Kundu Cisco Research Ramana Kompella Cisco Research Abstract The advent of quantum computing poses signicant threats to classical public-key cryptographic primitives such as RSA and elliptic-curve cryptography . As many critical network and secu- rity protocols depend on these primitives for key exchange and authentication, there is an urgent need to understand their quan- tum vulnerability and assess the progress made towards integrating post-quantum cryptography (PQC). This survey pr ovides a detailed examination of nine widely deploy e d protocols — TLS, IPsec, BGP, DNSSEC, SSH, QUIC, OpenID Conne ct, OpenVPN, and Signal Pro- tocol —analysing their cryptographic foundations, quantum risks, and the curr ent state of PQC migration. W e nd that TLS and Signal lead the transition with hybrid post-quantum key exchange already deployed at scale, while IPsec and SSH have standardised mecha- nisms but lack widespread production adoption. DNSSEC and BGP face the most signicant structural barriers, as post-quantum sig- nature sizes conict with fundamental protocol constraints. Across all protocols, key exchange proves consistently easier to migrate than authentication, and protocol-level limitations such as message size and fragmentation often dominate over raw algorithm perfor- mance. W e also discuss experimental deployments and emerging standards that are shaping the path towards a quantum-resistant communication infrastructure. 1 Introduction Quantum computing uses quantum mechanics to solve certain prob- lems exponentially faster than classical computers. In particular , Shor’s algorithm breaks the integer factorisation and discr ete log- arithm problems that underpin RSA, Die–Hellman, and elliptic- curve cryptography . Although large-scale quantum computers do not yet exist, adversaries can already r e cord encrypted trac today and decrypt it once quantum capabilities mature —the so-called “harvest-now , decrypt-later” threat. For data requiring long-term condentiality , this renders current protections inadequate well before a quantum computer is physically built. NIST conducted a multi-year eort to standardise quantum- resistant algorithms, r eleasing public drafts in 2023 [ 53 , 58 – 60 ] and publishing the rst PQC standards —FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA ) —in A ugust 2024 [ 54 – 57 ]. In ∗ This work was carried out when the author was at Cisco Research, San Jose, CA, during Summer Internship 2025. He is currently at Northeastern Univ ersity, Boston, MA. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for prot or commercial advantage and that copies bear this notice and the full citation on the rst page. Copyrights for components of this work owned by others than the author(s) must be honor ed. Abstracting with credit is permitted. T o copy otherwise, or republish, to post on servers or to redistribute to lists, r e quires prior specic permission and /or a fe e. Request permissions from permissions@acm.org. Conference acronym ’XX, W oodstock, N Y © 2018 Copyright held by the owner/author(s). Publication rights licensed to A CM. ACM ISBN 978-1-4503-XXXX -X/18/06 https://doi.org/XXXXXXX.XXXXXXX March 2025, NIST selecte d HQC as a fth key-encapsulation mecha- nism, with a draft standard expected in 2026 and nalisation by 2027. Draft NIST IR 8547 recommends deprecating quantum-vulnerable algorithms (RSA, ECDSA, EdDSA, DH, ECDH) by 2030 and fully retiring them by 2035. PQC primitives are now available in pr oduction-grade libraries. liboqs [ 63 ], from the Open Quantum Safe pr oject, supp orts inte- gration and evaluation of PQC algorithms across major operating systems. CIRCL [30] provides PQC primitives for the Go language. Amazon’s AWS-LC [ 2 ] incorporates PQC into A WS security ser vices. For constrained environments, pqm4 [ 68 ] targets ARM Cortex-M4 platforms. PQClean [ 25 ] oers portable C reference implementa- tions of NIST candidates, and libpqcrypto [ 8 ] collects diverse schemes for research and benchmarking. Howev er , algorithm availability alone does not imply protocol readiness. Integrating PQC into deployed protocols involves in- creased ke y and signature sizes, fragmentation and round-trip o ver- head, backward compatibility constraints, and a lack of operational experience at scale. Modern systems rarely depend on a single protocol: a typical enterprise deployment relies on TLS for web trac, IPsec for site-to-site VPNs, SSH for remote administration, DNSSEC for name resolution integrity , BGP for routing security , QUIC for low-latency transport, and OIDC for federated authenti- cation. Each of these protocols embeds classical cryptography in protocol-specic ways, and each faces distinct migration challenges. Y et e xisting studies tend to examine post-quantum migration for individual protocols in isolation, leaving practitioners and policy- makers without a unied view of where the transition stands, which protocols are furthest along, and where the critical bottlenecks lie. This paper addresses that gap by surveying nine widely deployed protocols — TLS, IPsec, BGP, DNSSEC, SSH, QUIC, OpenID Connect, OpenVPN, and the Signal Protocol. For each, we analyse its current cryptographic reliance, quantum vulnerabilities, post-quantum mi- gration eorts to date, and the challenges that remain. Our goal is to provide a single, cross-protocol reference that captures the state of the post-quantum transition as of 2025, enabling informe d migration planning across the protocol stack. 2 Background PQ cryptography is crucial to ensuring security in the face of emerg- ing quantum computing threats. A s quantum computers advance, they pose a risk to classical cryptographic algorithms, making the adoption of PQ key exchange mechanisms and digital signature schemes essential. Gradually , these PQ algorithms ar e being inte- grated into existing protocols to enhance se curity and future-proof systems against quantum attacks. Below we overview current PQ algorithms and some protocols that implement them. 2.1 KEM and Digital Signature Algorithms The algorithms are categorize d based on the mathematical problems they rely on, each oering dierent strengths, weaknesses, and Conference acronym ’XX, June 03–05, 2018, W o odstock, N Y T ushin Mallick, Ashish Kundu, and Ramana Kompella applications. A summary of the algorithms is pro vided in T able 1 and we expound on the categories below . Lattice-based cr yptography is a leading class of PQC, grounded in hard lattice problems such as the Shortest V ector Problem and Learning With Errors, which are believed to resist b oth classical and quantum attacks. These schemes oer favorable eciency and com- pactness, making them well suited for key exchange , encryption, and digital signatures. Notable examples include the key-exchange mechanisms CRYST ALS-K yber [ 14 ], N TRU [ 39 ], and SABER [ 22 ], as well as the digital signature scheme CRYSTALS-Dilithium, all of which are nalists in the NIST PQC standardization process. Code-based cryptography is rooted in the hardness of decod- ing random linear codes—a problem considered dicult ev en for quantum computers. While this category of algorithms oer small ciphertexts and fast encryption/decryption, their main drawback is the large size of public keys, which can be challenging to manage. Key exchange algorithm Classic McEliece[ 46 ] is a nalist in the NIST PQC standardization process for this category . Hash-based cryptography derives its se curity solely from cryp- tographic hash functions, making it especially w ell suited for digital signatures. Unlike lattice-based schemes, it do es not depend on complex mathematical structures but on the hardness of nding hash collisions, a problem for which quantum computers oer only limited advantage. While providing strong security guarante es, hash-based schemes generally incur larger signature sizes. Multivariate p olynomial cryptography is based on the hard- ness of solving systems of multivariate quadratic equations over nite elds, an NP-hard pr oblem. Schemes such as Rainbow [ 26 ] and GeMSS [ 67 ] are mainly designed for digital signatures and oer PQ security , albeit with large key and signature sizes. Rainbow is a nalist in the NIST PQC standardization process for this category . Isogeny-based cryptography exploits the diculty of comput- ing isogenies between elliptic curves and is notable for compact key sizes, making it attractive for constrained environments. However , in July 2022, KU Leuven researchers broke the SIKE [ 40 ] algorithm, a NIST fourth-round candidate, using a classical computer in 62 minutes, highlighting vulnerabilities in its underlying supersingular isogeny problem. Zero-knowledge(ZK) proof-base d PQ algorithms are designed to enable se cure verication processes without re vealing the un- derlying data, even in the face of quantum computing threats. Hybrid Algorithms. PQ hybrid algorithms combine conven- tional cryptography with PQC to ensure security during the transi- tion to a quantum-resistant era. They generate parallel key pairs— one from a classical scheme (e.g., RSA or ECC) and one from a PQ scheme—so that security is preserved as long as at least one component remains unbroken. Consequently , hybrid approaches provide robust, forward-looking protection and are expecte d to play a central role in securing sensitive data against both classical and quantum adversaries. Standardization. In 2022, NIST selecte d CRYSTALS-K yb er , F AL- CON, SPHINCS+ and CRYST ALS-Dilithium for standardization, releasing draft standards for three in 2023. In August 2024, NIST published the rst PQC standar ds [ 57 ]: FIPS 203 [ 54 ], FIPS 204 [ 55 ], and FIPS 205 [ 56 ]. These nalize K yber as ML-KEM (key encapsu- lation), Dilithium as ML-DSA ( digital signatures), and SPHINCS+ as SLH-DSA (stateless hash-based signatures). NIST is dev eloping a se cond set of standards, including FIPS 206 based on F ALCON (FN-DSA); however , as of 2025, no nal release has been announced. 3 Protocol Analyses In this section, we examine nine protocols that collectively secure communication across the Internet stack —from transport-layer encryption (TLS, QUIC) and network-layer tunnelling (IPsec, Open- VPN) to infrastructur e services (BGP, DNSSEC), remote administra- tion (SSH), federated identity (OpenID Connect), and end-to-end messaging (Signal Protocol). For each protocol, we describ e its cur- rent cryptographic foundations, assess its vulnerability to quantum attack, and review the post-quantum migration eorts undertaken to date, including standar disation progress, experimental deploy- ments, and op en challenges. The protocols are ordered to reect their dependencies: TLS is presented rst as several subsequent protocols —QUIC, OpenVPN, and Op enID Connect —build directly upon its handshake. 3.1 TLS (Transport Layer Security) TLS is the dominant protocol for secure communication on the Internet, used to encr ypt web (H T TPS) and application trac. It provides an authenticate d key exchange (the TLS handshake) to establish shared secrets, and uses those secrets for symmetric en- cryption of application data. Current pre-quantum cryptography . TLS 1.3, the latest ver- sion of the protocol, mandates ephemeral key exchange for ev er y session. By default, this uses elliptic-curve Die–Hellman (ECDHE) over X25519 or NIST P-256, ensuring that each connection derives fresh keying material. Older versions such as TLS 1.2 also supported nite-eld DH and static RSA key transport, but these modes ar e now deprecated in favour of the forward-secrecy guarantees pro- vided by ephemeral exchange. Ser ver authentication — and op- tionally client authentication — is performed via X.509 certicates carrying RSA or ECDSA public keys. During the handshake, the server signs a transcript of the exchange with its private key to prove possession, and the client validates this signatur e against a trusted certicate chain. In practice, RSA -2048 certicates remain widespread, though ECDSA P-256 certicates ar e increasingly com- mon due to their smaller size and faster verication. Once the handshake completes, all application data is protected using sym- metric AEAD ciphers — typically AES-128-GCM, AES-256-GCM, or ChaCha20-Poly1305 — which pro vide both condentiality and integrity in a single construction. These symmetric algorithms are considered safe against quantum attack, as Gro ver’s algorithm of- fers only a quadratic speedup that is not practical at scale with current key sizes. Quantum safety . Not quantum-safe currently . The ECDHE key exchange that underpins every TLS 1.3 session would b e broken by Shor’s algorithm, allowing an eav esdropper who captures the handshake to recover the shared secret and decr ypt all application data. TLS 1.3’s mandatory use of ephemeral key exchange pro vides forward secrecy — once session keys ar e discarded, past sessions cannot be retroactively compromised by br eaking the server’s long- term key alone — but this pr ote ction is precisely what the "harvest- now , decrypt-later" threat circumvents: an adversar y recording Study of Post antum status of Widely Used Protocols Conference acronym ’XX, June 03–05, 2018, W o odstock, N Y Category Name of Algorithm V ariants T ype Implementations Lattice-based CRYST ALS-Kyber K yber512, Kyber768, K yber1024 Key Encapsulation liboqs[ 63 ], CIRCL[ 30 ], pqm4[ 68 ], A WS-LC [2] FRODOKem[13] FRODO-640, FRODO-976, FRODO-1344 Key Encapsulation liboqs, CIRCL SABER LightSABER, SABER, FireSABER Key Encapsulation N/A NTRU NTRUEncr ypt, NTRU-HRSS-KEM, and N TRU Prime Key Encapsulation liboqs, CIRCL CRYST ALS-Dilithium Dilithium-2, Dilithium-3, Dilithium-5 Digital Signature liboqs, CIRCL, pqm4 F ALCON F ALCON-512, FALCON-1024 Digital Signature liboqs, pqm4 ML-DSA[52] ML-DSA-44, ML-DSA -65, ML-DSA-87 Digital Signature liboqs Code-based Classic McEliece Classic-McEliece-348864, Classic-McEliece- 460896, Classic-McEliece-6688128, Classic- McEliece-6960119, Classic-McEliece-8192128 Key Encapsulation liboqs BIKE [3] BIKE-L1, BIKE-L3, BIKE-L5 Key Encapsulation liboqs, pqm4 HQC[31] HQC-128, HQC-192, HQC-256 Key Encapsulation liboqs Hash-based SPHINCS+ [7] SPHINCS+-SHA2-128-simple, SPHINCS+- SHA2-192-simple, SPHINCS+- SHA2-256- simple Digital Signature liboqs XMSS[17] XMSS, XMSS-MT Digital Signature N/A Multivariate polynomial based Rainbow Rainbow-I, Rainbow-III, Rainbow-V Digital Signature N/A GeMSS GeMSS128, GeMSS192, GeMSS256 Digital Signature N/A Isogeny-based SIKE SIKE-p434, SIKE-p503, SIKE-p610 K ey Encapsulation liboqs Zero Knowledge-based PICNIC[19] PICNIC2-L1-FS, PICNIC2-L3-FS, PICNIC2-L5- FS Digital Signature N/A T able 1: Post-Quantum Cr yptography Algorithms today’s handshakes can derive session keys once a suciently pow- erful quantum computer becomes available. Server authentication is equally at risk, as both RSA and ECDSA signatures can be forged by a quantum adversary , enabling impersonation of any server whose certicate chain relies on these schemes. Since the entire W eb PKI — from root CAs down to end-entity certicates — is built on RSA and ECDSA, this vulnerability is systemic rather than conned to individual deployments. The symmetric AEAD ciphers used after the handshake (AES-GCM, ChaCha20-Poly1305) remain quantum-safe, as does the HKDF-based key derivation. In summary , TLS 1.3’s quantum exposure lies entirely in the handshake: key exchange and certicate-based authentication are vulnerable, while the symmetric data protection remains sound. Opus 4.6Extended 3.1.1 PQC Migration Eorts. Hybrid and Post-Quantum Key Ex- change: Several hybrid key exchange schemes for TLS 1.3 have been tested. For example, Google and Cloudare’s CECPQ e xp eriments combined classical ECDH with post-quantum KEMs ( e.g. X25519 + N TRU or SIKE in CECPQ2). Building on CECPQ2, Bernstein et al. [ 6 ] introduce a batch key generation technique for sntrup761 that outperforms b oth ntruhrss701 and pre-quantum schemes (NIST P-256, X25519) in TLS sessions p er second, while requir- ing only minimal changes to OpenSSL and no application-level modications. More recently , industry tests have focused on the NIST -selected KEM CRYST ALS-K yber . A preliminary variant of K yber has alr eady been deployed in TLS 1.3 by Google Chrome and Cloudare in hybrid mode to counter the “harvest-now , decrypt- later” threat. In fact, as of early 2024, 2% of Cloudare’s TLS 1.3 connections are using a post-quantum key agreement, a number expected to reach double digits by end of 2024. T o systematically assess the algorithm-level trade-os involved in such deployments, Paquin et al. [ 66 ] measure TLS 1.3 handshake times for a wide range of NIST candidate KEMs and signature schemes using the Open Quantum Safe (OQS) fork of OpenSSL under emulated network conditions with varying latency , bandwidth, and packet loss. The broader engineering challenges of integrating PQC into TLS and SSH—including algorithm negotiation and key combination for hybrid mo des—are addressed by Crockett et al. [ 21 ], who report on prototype implementations in Amazon s2n, OQS-OpenSSL, and OQS-OpenSSH that served as foundational infrastructure for much of the subsequent PQ- TLS research. Standards Progress: The IETF TLS W orking Group is actively standardizing PQC for TLS 1.3. One draft denes new TLS Named Groups for ML-KEM (K yber) at various security levels (512, 768, 1024 bits) to enable pure post-quantum key agreement in TLS [ 37 ]. Another draft describ es a hybrid key exchange design to com- bine classical ECDHE with a PQ KEM in the TLS handshake [ 36 ]. These drafts will allow TLS peers to negotiate hybrid or PQ key exchanges in a standard way (several test implementations exist using OpenSSL with lib oqs). The most comprehensive sur vey of the resulting landscape is provided by Alnahawi et al. [ 1 ], who classify existing post-quantum TLS proposals into three main cat- egories, conduct unied p erformance simulations, and identify open research problems. Their benchmarks conrm that hybrid K yber+X25519 key exchange adds only modest overhead, while more conservative schemes like FrodoKEM remain practical albeit slower . Post-Quantum Certicates: Migrating TLS authentication cer- ticates is more challenging. There are ongoing eorts to dene PQC signature algorithms in X.509 and TLS. IETF has proposals for composite/hybrid certicates that include both a classical and a PQ signature/public-key , so that browsers can continue to ac- cept classical signatures while gradually adding trust in PQ sig- natures [ 64 ]. Until standard PQ certicates are widely supported, any deployment of PQ signatures is ad-hoc (for instance, a server could oer a parallel PQ certicate chain in addition to the normal one) [ 20 ]. In a companion pair of studies, Sikeridis et al. [ 80 , 81 ] evaluate the joint overhead of post-quantum key exchange and authentication in TLS 1.3 and SSH, reporting latency increases of 1–300% for TLS depending on the algorithm combination, and pro- pose mixing dierent PQ signature algorithms across the certicate Conference acronym ’XX, June 03–05, 2018, W o odstock, N Y T ushin Mallick, Ashish Kundu, and Ramana Kompella chain to achie ve better latency trade-os than a uniform scheme. A fundamentally dierent approach to the authentication o verhead is taken by Schwabe et al. [ 79 ], who propose KEMTLS, an alter- native TLS 1.3 handshake that replaces signatures entirely with KEM-based authentication. Since post-quantum KEMs are generally more compact and faster than post-quantum signatures, KEMTLS signicantly reduces handshake data volume and is formally prov en secure in the standard model, though it delays authenticated server application data by one additional round trip. Performance and Feasibility: On dedicated hardware, Sosnowski et al. [ 82 ] conduct both black-b ox and white-box measurements of PQC in TLS 1.3, nding that most PQC algorithms are competitive with—or faster than—traditional schemes, that hybrid algorithms introduce negligible overhead, and that Dilithium outp erforms RSA - 2048 at all security levels. They also highlight that large PQC key sizes can trigger additional round trips in constraine d network environments. For embedded platforms, Bürstinghaus-Steinbach et al. [ 18 ] are the rst to integrate PQC into TLS, adding K yber and SPHINCS+ to the mbed TLS librar y and benchmarking across four ARM and Xtensa-based b oards; they nd that K yber performs comparably to ECC, while SPHINCS+ poses challenges primarily on the server side. In the Io T domain specically , Gonzalez and Wiggers [ 34 ] compare KEMTLS to post-quantum TLS 1.3 on a Cortex-M4 platform using W olfSSL across broadband, LTE-M, and Narrowband Io T scenarios, sho wing that KEMTLS reduces hand- shake time by up to 38%, low ers peak memor y consumption, and saves trac volume—underscoring the benets of signature-free authentication for resource-constrained devices. Challenges. Despite the progress outlined above, several chal- lenges remain. Post-quantum public keys, ciphertexts, and signa- tures are substantially larger than their classical counterparts, often causing handshake messages to exceed typical MT U sizes and trig- gering fragmentation or additional round trips. This size ination is especially problematic for authentication, where each NIST signa- ture nalist presents awkward trade-os for certicate migration — large outputs for Dilithium and SPHINCS+, and hardware-specic requirements for Falcon — which partly explains why p ost-quantum key exchange has outpaced authentication in real-world deploy- ment. Proposals such as KEMTLS and mixed certicate chains oer partial relief but require non-standard changes to the TLS state machine or certicate ecosystem, and the problem is comp ounded on embedded and IoT de vices where limited RAM, bandwidth, and computational power amplify the cost of larger cryptographic ob- jects. Beyond p erformance, most proposals that modify the TLS handshake ow lack rigor ous formal security proofs, making it di- cult to conrm that pr otocol-level changes preserve the guarantees TLS 1.3 was designed to provide . Deployment must also contend with a heterogeneous ecosystem of clients, servers, middleboxes, and certicate authorities, where hybrid modes increase negotiation complexity and composite certicates raise backward-compatibility questions that remain unresolved. 3.2 SSH SSH is a pr otocol for secure remote login and other secure network services. It provides an encrypted channel b etween a client and server , typically used for administration of systems (e .g. ssh into a Linux server). It uses its own key exchange and authentication mechanisms at the application layer (not TLS). Current cryptography . The SSH handshake supports Die- Hellman key exchange. Modern SSH (e .g. OpenSSH) by default uses elliptic-curve DH over Curve25519 (sometimes called X25519) for key exchange. It also supports classic DH gr oups (mo dp) and recently even hybrid methods (see below). In older or alternative congs, an RSA-based key exchange is possible (though rarely used now). The server proves its identity by possessing a host key . Common host key types are RSA, ECDSA, or Ed25519 (EdDSA). OpenSSH, for instance, now defaults to an Ed25519 host key b ecause of its strong security and small size, though RSA 3072+ or ECDSA P-256 keys are also seen. The host ke y is used to sign the key exchange to authenticate the server to the client. After the secure channel is established, the client can authen- ticate to the ser ver either with a password or using SSH public key authentication. The latter typically inv olves the client’s RSA, ECDSA, or Ed25519 key pair . This step is separate from the key exchange. SSH then derives symmetric session keys (usually AES-256 or ChaCha20 for encryption, and HMA C-SHA2 or similar for integrity ). These symmetric algorithms are quantum-safe ( AES and HMAC are safe if key sizes/hashes are large enough). Quantum safety . Not quantum-safe currently . The X25519 el- liptic curve Die–Hellman that secures most SSH sessions today would be broken by a quantum computer , just like in TLS. An eaves- dropper recording an SSH session’s initial key exchange could later derive the session keys and decrypt the entire session if they have a QC. (SSH, like TLS, pr ovides forward secrecy—once the session is over and keys discarded, only a captured transcript plus bro- ken DH would yield plaintext.). RSA and ECDSA host keys can be forged with quantum computing, meaning an attacker could poten- tially impersonate a server if they can break the signature when the server authenticates in the handshake. Ho wever , note that SSH host keys are often veried out-of-band (through a known hosts le or TOF U model), not a CA, but the fundamental vulnerability remains if an attacker can forge the handshake signature, they can pose as the server . Ed25519 (being an elliptic curve scheme) is equally vulnerable to Shor’s algorithm. Symmetric encryption remains ne (e .g. AES-256 in SSH is okay against quantum, aside fr om requiring at most a doubling of key length in theory). PQC migration eorts. Already in progress in implementa- tions. Hybrid key exchange in OpenSSH: OpenSSH introduce d a new key exchange method called sntrup761x25519-sha512@openssh.com, which is a hybrid of X25519 (ECDH) and a p ost-quantum KEM Streamlined N TRU Prime (sntrup761). This means the client and server perform both an X25519 exchange and an N TRU Prime exchange, and combine the results. An attacker would nee d to break both the classical and the p ost-quantum parts to recover the shared key . This was an early move to give SSH quantum resistance for the session key . As of OpenSSH 8.5, this hybrid KEX is supporte d (and was the default for a time). It has since been adjusted as the underlying N TRU Prime parameters ev olved, but OpenSSH remains one of the rst widely-used tools to include PQC. Study of Post antum status of Widely Used Protocols Conference acronym ’XX, June 03–05, 2018, W o odstock, N Y Standardization: Inspired by OpenSSH’s move, an Internet-Draft has be en written to codify the X25519+sntrup761 hybrid key ex- change for SSH in a standardized way [ 41 ]. This draft would make it easier for other SSH implementations to adopt the same metho d and ensure interoperability . So far , Op enSSH leads the charge, but we expect others (like LibreSSH, or SSH libraries) to follo w when standards solidify . Prototyping eorts by Crockett et al. [ 21 ] demonstrated that SSH can practically integrate hybrid (classical+PQ ) key exchanges and authentication, but exposed real implementation constraints such as message size limits and negotiation comple xity . Measurement studies by Sikeridis et al [ 80 ] showed that in practice , handshake overhead is driven more by signature and certicate size—and ev en TCP congestion behavior—than by raw KEM computation, indi- cating that network-layer dynamics are central to deployability . Formal analyses by Duong et al. [ 83 ] revealed subtle authentica- tion aws in draft hybrid SSH designs and proposed veried xes, while computational proofs in the PQ setting by Blanchet & Ja- comme [ 9 ]; Bencina et al. [ 5 ] provided stronger se curity mo dels capturing “har vest-now , decr ypt-later” threats and claried that hybrid SSH can achieve A CCE-style guarantees under carefully dened assumptions. Mor e recent protocol pr oposals by Qi & Chen [ 69 ] push further by designing SSH-specic hybrid key exchanges (e.g., ECDH+CSIDH) that embed authentication into MA C-based conrmation rather than relying solely on PQ signatures. Challenges. Post-quantum migration of SSH is not a simple primitive swap but a systemic r edesign challenge. Hybrid key ex- change must securely combine classical and PQ components with- out inducing do wngrade or authentication aws, while formal guar- antees must now hold against quantum-capable adversaries under stronger models. At the same time, PQ signatures and larger key ma- terial signicantly increase handshake size , making network eects (TCP congestion, fragmentation, message limits) a primary p er- formance bottleneck rather than raw computation. Compounding this, SSH must preserve backward compatibility during a prolonged transition, manage expanded negotiation complexity , and operate amid evolving standardization and primitiv e maturity . 3.3 QUIC QUIC is a mo dern transp ort protocol originally developed by Google and now standardized by the IETF . It runs over UDP and provides stream multiplexing, low latency connection establishment, and integrated security equivalent to TLS 1.3. H T TP/3 is built on top of QUIC. Essentially , QUIC implements a TLS 1.3 handshake within its own protocol to set up encr yption between client and server , then carries data streams. Current cr yptography . QUIC uses the TLS 1.3 handshake for cryptographic negotiation and key exchange, but encapsulates it in QUIC packets. So it uses the same algorithms as TLS 1.3, typically an ECDHE (X25519) key exchange , with ser ver authentication via an RSA/ECDSA certicate, and symmetric AES-GCM or ChaCha20 encryption for packets. After the handshake, QUIC encrypts all payload and most header elds using the derived TLS keys. Integrity is ensured via AEAD (the GCM or Poly1305 tags). In short, QUIC’s security is equivalent to TLS 1.3’s se curity . The main dierence is QUIC has some protocol-level integrity for its header (using a header protection algorithm), but that also relies on symmetric crypto (e.g. an AES or ChaCha mask) derived from the handshake keys. Quantum safety . Not quantum-safe currently . Since QUIC relies entirely on the TLS 1.3 handshake for cryptographic negotiation, it inherits the same quantum vulnerabilities. The X25519 key ex- change underpinning most QUIC connections would b e broken by Shor’s algorithm, allowing an eavesdropper who records the hand- shake to later derive session keys and decrypt all trac — including the payload and header elds that QUIC encrypts b eyond what TLS traditionally protects. Server authentication relies on the same RSA or ECDSA certicates as TLS 1.3, both vulnerable to quantum forgery . QUIC’s header protection mechanism uses symmetric prim- itives (AES or ChaCha20) and is quantum-safe in itself, but only if the handshake keys from which it derives were securely estab- lished — which they would not be under a quantum adversary . The symmetric AEAD encryption (AES-GCM or ChaCha20-Poly1305) used for packet protection remains sound against quantum com- puters. In short, QUIC’s quantum vulnerability prole is eectively identical to that of TLS 1.3: key exchange and authentication are at risk, while symmetric encryption and integrity mechanisms remain safe. PQC migration eorts. Cloud-scale experiments by Raavi et al.[ 70 , 71 ] show that QUIC generally outperforms TCP/TLS even under PQ authentication, maintaining lower handshake latency and variance across global RT T conditions, with lattice-based sig- natures (Dilithium, Falcon) proving practical while larger schemes increase overhead. Cryptography-centric dissection by Kempf at al.[ 42 ] reveals that handshake byte size—not raw computation—is the dominant cost driver , making compact KEMs like K yber and ecient signatures like Dilithium or Falcon viable, while SPHINCS+ imposes prohibitive latency due to large signatures. Comprehen- sive end-to-end evaluations by Rigon at al. and Montenegr o et al. [ 49 , 76 ] conrm that ML-KEM/K yber consistently delivers the b est tradeo across handshake latency , throughput, CP U, and mem- ory , that hybrid ML-KEM+ECDHE adds only marginal overhead while strengthening transitional security , and that QUIC damp- ens PQ penalties better than TLS, esp ecially under lossy condi- tions. Embedded-system analysis by Dong et al.[ 29 ] further demon- strates that K yber can outperform classical ECDH even on resource- constrained ARM platforms and that QUIC’s fast UDP-base d hand- shake helps oset PQ computational costs, though high-se curity levels and hash-based signatures signicantly inate latency . Challenges. The migration of QUIC to post-quantum cr yptog- raphy benets from the protocol’s UDP-based design and reduce d round-trip handshake, which naturally damp ens some of the la- tency penalties introduced by larger PQ primitives. Howe ver , sev- eral challenges remain. The dominant cost driver in post-quantum QUIC is handshake byte size rather than raw computation, mean- ing that algorithms with large public keys or signatures — partic- ularly SPHINCS+ — can impose prohibitiv e overhead even when their computational cost is manageable. Since QUIC multiplexes all handshake and application data over UDP without the segmen- tation guarantees of TCP , oversized PQ handshake messages risk exceeding path MT U limits and triggering fragmentation at the IP layer , which interacts poorly with middleboxes and rewalls that may drop or reorder UDP fragments. While compact KEMs Conference acronym ’XX, June 03–05, 2018, W o odstock, N Y T ushin Mallick, Ashish Kundu, and Ramana Kompella like K yb er and ecient signatures like Dilithium or Falcon have proven practical, the lack of a standardised post-quantum QUIC prole means that algorithm selection and hybrid negotiation re- main ad hoc across implementations. On resource-constrained and embedded platforms, QUIC’s fast handshake helps oset PQ compu- tational costs at lower security levels, but high-security parameter sets and hash-based signatures can still inate latency to the point where the protocol’s speed advantages over TLS ar e eroded. Finally , QUIC’s tight integration of transport and cryptography — while architecturally elegant — means that any PQ-related changes to the handshake have implications for congestion control, connection migration, and 0-RT T r esumption, interactions that are not yet well understood and have received limited formal analysis. 3.4 IPsec (IKEv2) IPsec is a suite of protocols for securing IP communications (VPNs) at the network layer . It consists of the Internet Key Exchange (IKEv2) protocol for negotiating cryptographic keys and security parameters, and the AH/ESP protocols for authenticating and en- crypting IP packets. Current Cryptography . Current cr yptography . IPsec oper- ates in two phases. The rst phase uses IKEv2 to negotiate se- curity parameters and establish a shared secret. IKEv2 performs a Die–Hellman key exchange — typically using nite-eld DH groups (modp2048, modp3072) or elliptic-cur ve DH (e .g. Curve25519 or NIST P-256) — to derive keying material. Peers authenticate each other either through digital signatures (RSA or ECDSA backed by X.509 certicates), which is common in site-to-site VPN deploy- ments, or through pre-shar e d symmetric keys, which ar e simpler but less scalable. The second phase establishes one or more IPsec Security Associations (SAs) that protect the actual data trac. The Encapsulating Se curity Payload (ESP) protocol handles packet-lev el protection, using symmetric ciphers such as AES-CBC or AES-GCM for encryption and HMAC-SHA -256 or the GCM authentication tag for integrity . These symmetric algorithms are generally consid- ered quantum-resistant pro vide d suciently large keys are used. IKEv2 also supports periodic re-keying to r efresh session keys over long-lived tunnels, performing a new DH exchange each time to maintain forward secrecy . Quantum Safety . Not quantum-safe currently . The Die–Hellman key exchange at the heart of IKEv2 — whether nite-eld or elliptic- curve — would be broken by Shor’s algorithm, allowing an eaves- dropper who r e cords the IKE handshake to later recov er the shared secret and decrypt all ESP-protecte d trac in that session. Unlike TLS, where sessions ar e typically short-lived, IPsec tunnels often persist for e xtende d periods with periodic r e-keying; if the underly- ing DH exchange is compromised, all trac within a tunnel’s life- time is exposed. Peer authentication via RSA or ECDSA signatures is equally vulnerable — a quantum adversary capable of forging these signatures could impersonate a VPN gateway and establish rogue tunnels, a particularly severe risk in site-to-site deplo yments where IPsec protects entire network segments rather than individ- ual connections. Pre-shared key authentication, while not directly broken by quantum computers, is only as strong as the key ex- change it accompanies; if the DH-deriv e d secret is compromised, the PSK alone does not protect session condentiality . The symmet- ric encryption (AES) and integrity me chanisms (HMA C-SHA2) used by ESP after the handshake remain quantum-safe with current key sizes. In summary , IPsec’s quantum vulnerability centres on IKEv2: both the key exchange and certicate-based authentication are at risk, while the symmetric data-plane protections remain sound. PQC Migration of IPse c. Hybrid Ke y Exchange: Recent standards allow mixing a pre-shared key (PSK) into the IKEv2 key derivation, yielding quantum-resistant keys even if the DH exchange is later broken. RFC 8784 (2020) in- troduces this “Post-quantum Preshared Key” extension to augment IKEv2 with entropy from a pre-shared secret [ 85 ]. Early practical ex- ploration of this direction is provided by Herzinger et al. [ 38 ], who examine hybrid key exchange in real-world IKEv2 deployments, noting that the lack of condence in any single post-quantum algo- rithm motivates combining at least two schemes so that the shared secret remains secure as long as one prevails; however , the large payloads of some PQ algorithms require signicant protocol-level changes. Blanco-Romero et al. [ 10 ] push this further by proposing a hybrid architecture for IPsec that combines classical, post-quantum, and quantum key distribution ( QKD) sources into the ke y deriva- tion process, providing defence in depth acr oss multiple layers of cryptographic assurance. Multiple Key Exchanges: The new RFC 9370 (2023) extends IKEv2 to perform multiple key exchanges (e.g. an ECDH plus a p ost- quantum KEM) during session setup. This allows negotiating one or more PQC algorithms alongside the classical DH. The shared key can b e formed by combining secrets such that an attacker must break all key exchanges to defeat the security . In other words, if at least one component algorithm is quantum-resistant, the nal IKEv2 shared secret is quantum-safe [ 43 ]. A detailed performance breakdown under this model is provided by Bae et al. [ 4 ], who evaluate a range of NIST Round 3 KEMs (K yber , N TRU, Saber) and regionally developed algorithms within the strongSwan IPsec im- plementation via libo qs, analysing execution spe ed and packet size across security lev els. Their r esults show that higher security levels generally increase latency and packet sizes, with K yber oering the best balance between se curity and performance. Gazdag et al. [ 32 ] take these eorts towards standardisation by executing the rst steps needed for quantum-resistant VPNs on both Layer 2 (MA C- sec/MKA) and Layer 3 (IPsec/IKEv2), identifying the necessary protocol modications and testing them in practice. Deployment and T esting: Despite these standardisation eorts, T wardokus et al. [ 84 ] demonstrate that the proposed IETF RFCs for quantum-resistant IKEv2 remain largely untested under real- istic conditions. Using a repr oducible testb ed deployed over both lossy wireless links and the internationally distributed F ABRIC testbed, they reveal severe bottlenecks under high round-trip times and non-trivial packet loss, reporting a 400–1000-fold increase in data overhead ov er high-loss wireless links. On the physical layer side, Lawo et al. [ 45 ] report on the rst experimental IPsec tunnel secured by Falcon, Dilithium, and K yber over b oth wireless and ber-optic links; since strongSwan did not natively supp ort PQC at the time, they perform authentication and key exchange externally and establish the IPsec conne ction using the exchanged pre-shared key . Study of Post antum status of Widely Used Protocols Conference acronym ’XX, June 03–05, 2018, W o odstock, N Y Challenges. The migration of IPsec to post-quantum cryptogra- phy faces challenges that mirror — and in some cases exceed — those encountered in TLS. IKEv2 was designed around the assumption of compact key exchange payloads, and its fragmentation mecha- nisms are less matur e than those in TLS 1.3, making the handshake particularly sensitive to the message size ination introduced by PQ algorithms. In practice, this can translate to orders-of-magnitude in- creases in data o verhead ov er lossy or bandwidth-constrained links, suggesting that VPN deployments over wireless, satellite , or high- latency networks may require protocol redesign rather than simple algorithm substitution. Unlike TLS, where hybrid key exchange has already seen large-scale deployment by browser v endors and CDNs, IPsec adoption of PQC remains largely conne d to research prototypes and testbeds, with no major commercial VPN product shipping post-quantum IKEv2 by default. The lack of native PQC support in widely used IPsec daemons further slows adoption, as workarounds like p erforming key exchange externally and injecting pre-shared keys add operational complexity and preclude standard re-keying. Finally , formal security analysis of post-quantum IKEv2 extensions is still in its early stages, with only limited automated proofs available for the modie d handshake ows — a gap that needs to b e closed before these extensions can b e condently stan- dardised and deployed at scale. 3.5 OpenVPN OpenVPN is a popular open-source VPN protocol/software that secures IP trac at the transport layer (it can be thought of as similar in purpose to IPsec, but in user space). It uses TLS (or a TLS-like handshake) to establish a se cure tunnel between client and server , and then encrypts IP packets or TCP streams through that tunnel. Current cr yptography . Op enVPN uses a TLS handshake — typically TLS 1.2, though newer versions support TLS 1.3 — to es- tablish a secure control channel between the VPN client and server . During this handshake, peers authenticate using X.509 certicates, most commonly RSA -2048 or RSA-4096 for the server , with clients presenting either their own certicate or a pre-shared key depend- ing on the deployment conguration. Key exchange follows the standard TLS model, using ECDHE (e.g. X25519 or NIST P-256) or , in older congurations, RSA key transport to deriv e session keys. In essence, the authentication and key exchange algorithms are whatever the underlying TLS prole dictates, making OpenVPN’s handshake security equivalent to that of web TLS. Once the hand- shake completes, OpenVPN encrypts user trac on a separate data channel using symmetric ciphers — most commonly AES-256 in CBC or GCM mode, or ChaCha20-Poly1305 for b etter performance on devices lacking hardware AES acceleration — with HMAC-SHA - 256 providing integrity where AEAD is not used. A separate control channel handles session management, re-keying, and keepalive messages, and is protected directly by the TLS-derived keys. Open- VPN also supports an optional static pre-shar e d key mode (tls-auth or tls-crypt) that wraps the control channel in an additional sym- metric encr yption layer , providing a rst line of defence against denial-of-service attacks and unauthenticated probing before the TLS handshake even begins. Quantum safety . Not quantum-safe currently , and inherits all of TLS’s quantum vulnerabilities since its security model is built di- rectly on top of a TLS handshake . The ECDHE or RSA key exchange used during session establishment would b e broken by Shor’s algo- rithm, allowing an adversary who records the VPN tunnel setup to later derive session keys and decrypt all encapsulated user trac — eectively stripping away the VPN’s condentiality entirely . The RSA or ECDSA certicates used for peer authentication are equally vulnerable to quantum forgery , meaning an attacker could imper- sonate a VPN server or client and establish rogue tunnels. This is particularly concerning in enterprise and remote-access scenarios where Op enVPN protects sensitive internal network trac, as a single compromised handshake exposes not just one connection but all trac routed through that tunnel. The tls-auth and tls-cr ypt pr e- shared key layers, being symmetric, are quantum-safe and w ould continue to prevent unauthenticate d access to the control chan- nel, but they do not protect the key exchange itself — they merely gate access to it. The symmetric data-channel encryption ( AES-256, ChaCha20) and integrity mechanisms (HMA C-SHA -256, GCM tags) remain quantum-safe. In summary , OpenVPN’s quantum exposure is identical to that of the TLS version it runs on: key exchange and certicate authentication are at risk, while symmetric pr ote ctions remain sound, and the protocol’s VPN-specic additions (tls-auth, tls-crypt) oer no mitigation against a quantum adversary targeting the handshake. PQC migration eorts. TLS 1.3 in OpenVPN: Since OpenVPN can now use TLS 1.3 ( which has a standard extension mechanism for new ke y exchange groups), once TLS 1.3 gets ocial PQ groups (e .g. via the draft for ML-KEM K yber), OpenVPN will be able to use them out-of-the-box by relying on the TLS library . Microsoft Research’s PQCrypto-VPN: Microsoft published an ex- perimental fork of OpenVPN that integrates post-quantum algo- rithms [ 75 ]. This project used the Op en Quantum Safe ( liboqs) library to add PQ key exchange into OpenVPN’s TLS handshake. It allowed testing of algorithms like FrodoKEM or others in a VPN scenario, evaluating performance and interoperability . The fork demonstrated that one can have a working OpenVPN with quantum- resistant key exchange , but it was for research (not production). OpenVPN community developments: OpenVPN’s developers have been aware of PQC. A 2022 patch on the OpenVPN mailing list enabled support for quantum-safe and hybrid key exchanges via OpenSSL 3.0’s provider interface [ 24 ]. OpenVPN can be built with OpenSSL, and OpenSSL 3.0+ can dynamically load the Open Quan- tum Safe (OQS) provider , which includes PQ algorithms. The patch ensured that if Op enSSL oers a PQ KEM (like K yber) as a TLS group, OpenVPN can negotiate it just like any other cipher suite . This patch indicates active interest and likely will be part of Open- VPN 2.6+ or 2.7. 3.6 BGP and RPKI BGP is the routing protocol that connects the global Internet, use d between autonomous systems (AS) to exchange network reachabil- ity information. By default, BGP has minimal security , which le d to extensions like RPKI and BGPsec to provide origin authentication and path validation for routes. Conference acronym ’XX, June 03–05, 2018, W o odstock, N Y T ushin Mallick, Ashish Kundu, and Ramana Kompella Current cryptography . Classic BGP uses TCP with MD5 or TCP- AO for authentication of BGP sessions. These ar e symmetric integrity che cks (MD5 or HMA C) on each packet – while MD5 is outdated, TCP-A O with a strong HMA C (SHA -1/256) can pro- tect BGP sessions from tampering. Symmetric keys here are not threatened by quantum attacks if chosen with sucient length. The Resource Public Key Infrastructure (RPKI) provides a way to verify that an AS is authorized to originate a route for a given IP prex. RPKI uses X.509 certicates and digitally signe d objects (RO As). Current RPKI deployments typically use RSA or ECDSA for those signatures (e.g. a common prole is RSA -2048 or ECDSA P-256 for certicates and RO As). BGPsec is an extension where each AS cryptographically signs the routing announcements it propagates. BGPsec uses ECDSA P-256 with SHA -256 as its mandatory algo- rithm for signing BGP UPD A TE messages. Each BGPse c speaker has a signing key (provisioned via RPKI certicates) to sign r oute updates, and receivers validate the signature chain. Quantum safety . Not quantum-safe. BGPsec’s use of ECDSA means that a quantum attacker could forge route announcements or invalidate legitimate ones by breaking the signatur es. The RPKI’s use of RSA/ECDSA for certicates and ROAs is similarly vulnerable – a quantum-capable adversary could p otentially hijack IP prexes by forging RPKI certicate material or BGPsec signatures. While the symmetric session protections (TCP-A O with HMAC) would remain secure, they do not protect against attacks on route authenticity . In essence, the integrity of routing information relies on digital signatures that are quantum-vulnerable. It’s worth noting that BGP as a whole has not fully deployed BGPsec globally (adoption is limited due to complexity), but to the extent we rely on RPKI and BGPsec for security , those aspects are at risk in a p ost-quantum scenario. PQC migration eorts. V ery early stage. There is currently no deployed post-quantum version of BGPsec or RPKI, but the ne ed is recognized. The BGPsec design anticipated the need for cr yptographic agility . RFC 8608 explicitly notes that “BGPsec will require adoption of updated key sizes and a dierent set of signature and hash algo- rithms over time ” , and that the prole should be updated with new algorithms when appropriate [ 51 ]. This provides a pathway for introducing PQC algorithms into BGPsec. Academic groups and NIST have started looking at PQ deploy- ment for BGP – for e xample, NIST’s BGP Secure Routing Extension (BGP-SRx) test suite could be used to experiment with alternate algorithms [61, 62]. Doesburg [ 28 ] argues that RPKI’s reliance on RSA makes it vul- nerable to future quantum attacks and shows that post-quantum migration—particularly via hybrid signatures like Falcon—can be feasible if performance overhead is mitigated through optimiza- tions and a more practical, mixed-tree deployment model rather than rigid top-down transitions. Miesch et al. [ 48 ] complement this by demonstrating that RPKI’s lack of algorithm agility is the funda- mental barrier to both PQ and classical upgrades, and that naïve migration strategies risk overwhelming bandwidth and validation capacity; they propose a dual-tree ( legacy + mixed) approach to enable incremental, incentive-compatible deployment. Challenges. The notable obstacles include performance and message size, a BGPsec update may b e processed by many routers, so signature verication must be fast. PQC signatures like Dilithium or Falcon are computationally heavier (though Falcon is quite fast in verication) and larger in size. A BGPsec UPDA TE currently carries an ECDSA signature of 64 bytes per AS hop; a Dilithium sig- nature could be 2–3KB, which, with many hops, might considerably bloat BGP messages and strain router memory/CP U. T echniques to mitigate this ( e.g. signing only critical parts, or using more compact PQ signatures if available) w ould b e explored. Another av enue is stateful hash-based signatures (like XMSS) for BGP, since r outing updates are sequential and could use stateful signatures. These are quantum-safe and could potentially b e ecient per update, but op- erational complexity (managing one-time ke ys acr oss reboots/route changes) is a barrier . 3.7 DNSSEC DNSSEC adds cr yptographic authenticity to DNS. It uses digital signatures to ensure that DNS r esponses ( like the IP address for a domain name) haven’t been tampered with. It introduces a hierar- chy of public keys: the DNS root, top-level domains, and individual domains each have key pairs used to sign DNS recor ds. Resolvers (DNS clients) verify these signatures to trust the DNS answers. At each zone (e.g. example.com), the zone signing key (ZSK) signs DNS record sets (RRsets). Those signatur es (RRSIG records) are distributed via DNS. A chain of trust is formed: the parent zone signs a delegation to the child’s key (DS record). Ultimately , a validating resolver uses the root’s public key (the anchor) to verify the whole chain of signatures. Current cr yptography . DNSSEC supports various algorithms. The most widely used are RSA (with SHA -256, designated as algo- rithm 8 or 8+SHA -256 in DNSSEC), ECDSA (P-256 with SHA -256, and P-384 alg 14), and increasingly EdDSA (Ed25519 and Ed448). For example, the DNS root is currently signed with an RSA -2048 key (SHA -256 digest), and many TLDs and domains use either RSA - 2048 or ECDSA P-256 for zone signing. Ed25519 is valued for its small signature size and is seeing adoption for smaller zones. RSA keys in DNSSEC are often 2048-bit ( some larger like 3072 or 4096 for root KSKs). ECDSA P-256 ke ys are 256-bit but provide similar security with much smaller signatures (64 bytes vs 256 bytes for RSA -2048 sigs). Ed25519 likewise has 64-byte signatures. Quantum safety . Not quantum-safe. All the algorithms in prac- tical use for DNSSEC (RSA, ECDSA, EdDSA ) are based on factor- ization or discrete log problems, which are breakable by a quan- tum computer . An attacker with a quantum computer could forge DNSSEC signatures, allowing them to create fake DNS records (e.g. trick users into connecting to an attacker’s IP instead of a real site) even if DNSSEC is deployed. They could impersonate entire zones by forging RRSIGs on DNS answers. They could also forge the chain of trust ( e.g. pretend to be a parent TLD or even the root by forging signatures with the root’s private key ). The integrity of DNSSEC- signed data would collapse under a quantum adversary , negating the security DNSSEC provides (which is to prevent DNS spoong/- cache poisoning). DNSSEC does not protect condentiality (DNS queries/responses are public), so the concern is integrity/authentic- ity . Quantum breaks would let an attacker undetectably sabotage name resolution. Study of Post antum status of Widely Used Protocols Conference acronym ’XX, June 03–05, 2018, W o odstock, N Y PQC migration eorts. Industry and academic eorts have begun testing PQC within the DNS e cosystem. In 2023–2024, a col- laboration between deSEC, SandboxA Q, and Pow erDNS developers deployed experimental DNSSEC-signed zones using p ost-quantum signature schemes including Falcon-512, Dilithium-2, SPHINCS+, and the stateful hash-based scheme XMSS [ 23 ]. These were not purely simulated environments — the zones were op erationally signed and ser ved to real resolvers, allowing the researchers to observe how e xisting DNSSEC validators handle the larger ke y and signature sizes introduced by PQC, and to measure the resulting impact on query latency and UDP/TCP fallback b ehaviour . Modied versions of BIND 9 and PowerDNS w ere used as the authoritative servers in these experiments. Muller et al. [ 50 ] systematically evaluate NIST PQ signature candidates against DNSSEC’s practical limits (notably the 1232- byte UDP safety threshold), showing that only a few schemes (e.g., Falcon-512) are even close to deployable without protocol changes and arguing that DNSSEC cannot treat PQ as a drop-in crypto- graphic swap . Goertzen & Stebila [ 33 ] intr o duce ARRF (application- layer request-based fragmentation), where oversized DNSSEC re- sponses are split and explicitly r e quested at the DNS layer rather than relying on IP fragmentation or TCP fallback; their implemen- tation with Falcon, Dilithium, and SPHINCS+ shows lower res- olution latency and, in some cases, lower bandwidth than TCP fallback, while identifying memory-exhaustion risks from adversar- ial fragment metadata. McGowan et al. [ 47 ] further analyze those ARRF security risks and propose mitigations to pre vent resource- allocation attacks during reassembly . A cross a sequence of works, Rawat and Jhanwar progressively explore increasingly radical de- sign points for enabling p ost-quantum DNSSEC. They rst pro- pose QNAME-based fragmentation (QBF) [ 72 ], which keeps the signature-based model intact but enables oversized PQ r esponses to be reconstructed over UDP in a single round trip using standard DNS records. They then optimize the fallback path with T urboDNS [ 73 ], reducing the latency o verhead of TCP fallback and incorpo- rating cookie-based safeguards to mitigate abuse. Most recently , with SL-DNSSEC [ 74 ], they mov e beyond fragmentation entirely , replacing signatures with a quantum-safe KEM+MA C construction to eliminate large signature overhead while pr eser ving DNSSEC’s security goals. Pan et al. [ 65 ] advocate double-signing ( classical + PQ) combined with fragmentation as a transitional hedge against both quantum and immature-PQ risks. Finally , Schutijser et al. [ 78 ] provide an op erator-focused evaluation, signing real TLD-scale zones (.nl, .se, .nu) with Falcon-512 and MA Y O-2, showing PQ sign- ing is operationally feasible but with measurable zone size and CPU trade-os. Challenges. The main obstacle to PQ adoption in DNSSEC is signature and key size ination, which conicts with DNS’s UDP- oriented design and practical ∼ 1232-byte response limit. Large PQ signatures frequently trigger IP fragmentation or TCP fallback, in- creasing latency , bandwidth use , and operational complexity , while also e xpanding zone sizes and raising signing and validation costs— especially for large operators. Equally challenging is deployability at Internet scale. Fragmen- tation schemes, TCP optimizations, or dual-signing approaches introduce new protocol logic and potential attack surfaces (e.g., resource exhaustion), and must remain backward-compatible with heterogeneous resolvers and middleboxes. As a result, PQ migration in DNSSEC is fundamentally a systems and ecosystem coordination problem, not just a cryptographic upgrade. 3.8 OpenID Connect OpenID Conne ct is an identity authentication protocol built on O Auth 2.0. It allows clients (like a web app) to verify a user’s identity by obtaining information (in an ID T oken) from an Identity Provider (IdP) like Google, Microsoft, etc. For example, “Log in with Google” uses Op enID Connect. The ID T oken is typically a JSON W eb T oken ( JWT) signed by the IdP, which the client can cr yptographically verify . Current cr yptography . OIDC ows o ccur over HT TPS (H T TP + TLS) — for instance, the user is redirected to the IdP , and tokens are sent over H T TPS. So the transport security is TLS (with its classical cr ypto). Thus, all the TLS considerations (RSA/ECDHE, etc.) apply here as well. The core of OIDC is the ID T oken, which is a JWT ( JSON W eb T oken). This is usually signed using JSON W eb Signature ( JWS). Common algorithms are RSA with SHA-256 (often called RS256 in JWT parlance) or ECDSA P-256 with SHA-256 (ES256). In practice, RS256 is very widely used as a default in many systems. The IdP has a key pair (RSA or EC) and publishes the public key via a JWKS ( JSON W eb Key Set) endpoint. The relying party (client) downloads that and uses it to verify the JW T signature, ensuring the token was issued by the genuine IdP. OIDC can also encrypt tokens (using JSON W eb Encryption – JWE) but this is less common; usually tokens are just signed and sent via H T TPS, relying on TLS for condentiality . Sometimes, after obtaining an ID T oken, the client may call a UserInfo API at the IdP to fetch more prole info . That API call is over HT TPS and secured by OA uth access tokens, but not directly relevant to PQ crypto (mainly symmetric bearer token plus TLS). Quantum safety . Not quantum-safe currently , though the threat model diers from transport-layer protocols. OIDC’s transport se- curity inherits all of TLS’s quantum vulnerabilities — the X25519 key exchange and RSA/ECDSA certicates protecting HT TPS chan- nels between the user , IdP, and relying party are all susceptible to Shor’s algorithm. Howev er , the more distinctive risk lies in the ID T oken itself. The JWT signatures that form the trust anchor of OIDC are typically RS256 (RSA) or ES256 (ECDSA ), both of which a quantum adversary could forge. An attacker able to break the IdP’s signing key could mint arbitrar y ID T okens that any relying party would accept as genuine, eectively impersonating any user to any service that trusts that IdP — a far broader blast radius than compromising a single transport session. Since IdP public keys are published via JWKS endpoints and often long-lived, a quantum ad- versary would not even need to intercept trac; they could simply download the public ke y and compute the corresponding private key oine. T oken encryption ( JWE), wher e used, typically relies on RSA or ECDH key wrapping and w ould similarly be broken. The symmetric components — such as AES content encryption within JWE or HMA C-based token validation in certain congurations — remain quantum-safe. In summary , OIDC’s quantum exposure is twofold: it inherits TLS’s transport vulnerabilities, and it adds an application-layer risk through the forgery of JWT signatures that underpin the entire federated trust model. Conference acronym ’XX, June 03–05, 2018, W o odstock, N Y T ushin Mallick, Ashish Kundu, and Ramana Kompella PQC migration eorts. Schardong et al. [77] present the rst full-stack empirical evaluation of post-quantum OA uth 2.0 and OpenID Connect, replacing classical TLS key e xchange and JW T signatures with K yber and NIST nalist PQ signatures, and bench- marking a realistic multi-step OIDC deployment. They show PQ identity is technically feasible and competitive in low-latency set- tings, but increased key and signature sizes signicantly amplify TLS handshake overhead under higher latency , making network eects — not computation — the primary bottleneck in practical PQ migration. The IETF JSON Object Signing and Encryption ( JOSE) work- ing group and the COSE (CBOR Object Signing and Encr yption) working group are standardizing how to use PQC algorithms in JSON/CWT tokens. Drafts exist for encoding CRYST ALS-Dilithium, Falcon, and SPHINCS+ signatures in JWT/COSE format [35]. Challenges. Post-quantum migration of O Auth 2.0 and OpenID Connect faces two core challenges: p erformance scaling and ecosys- tem coordination. Larger PQ ke ys, certicates, and signatures in- ate TLS handshakes and token exchanges, compounding latency across the multi-step identity w orkow and stressing bandwidth- constrained or mobile environments. At the same time, identity systems depend on tightly coupled components — TLS stacks, JW T standards, discovery endpoints, certicate infrastructures, SDKs, and federated trust frameworks—so introducing PQ algorithms re- quires synchronized upgrades across the entire ecosystem. Hybrid fallback modes may ease transition but risk complexity and resid- ual classical exposure, making PQ identity migration a systemic architectural shift rather than a simple algorithm swap. 3.9 Signal Protocol The Signal Protocol (developed by Op en Whisper Systems) is an end-to-end encryption protocol for secure messaging. It’s used in the Signal messenger , WhatsApp, and other apps to ensure that only the intended recipient of a message can read it. Signal Protocol introduced the Double Ratchet algorithm and X3DH (Extended Triple Die–Hellman) key agreement for asynchronous, se cure key exchange b etween users. In brief, when two people start a conversation, they perform an initial key agreement (X3DH) using a combination of long-term keys, semi-long-term (signed pre-keys), and one-time pre-keys – all based on Die–Hellman over elliptic curves. They then enter a Double Ratchet where each message uses a new symmetric key derived fr om the pre vious, providing for ward secrecy and post-compromise security . When User A wants to start a chat with User B, A obtains B’s identity key , B’s signed pre-key (and signature to verify it, using Ed25519), and one of B’s one-time keys. A then does DH between various combinations of these keys (A ’s identity & B’s pre-key , A ’s ephemeral & B’s identity , etc.) — hence “T riple DH” — to derive a shared master secret. Current cr yptography . Signal uses Curve25519 (elliptic curve Die–Hellman on curve Montgomery 25519) for all its DH oper- ations. Each user has an identity key pair ( Cur ve25519), a signed pre-key (Cur ve25519, signed with the identity key via Ed25519 signature), and a set of one-time pre-keys ( Cur ve25519). After X3DH, both parties have a shared secret and start exchang- ing messages. Each message uses a symmetric key evolved via the ratchet (which involves a DH each time someone sends a message to mix in new entropy , plus a hash ratchet). The ratchet DH again uses Curve25519: each party generates a new ephemeral Die–Hellman key for each ratchet step and exchanges public values, deriving new chain keys. Signal protocol uses AES-256 (in CBC mode in older versions, now often X ChaCha20 for the Double Ratchet in some implemen- tations) and HMA C-SHA256 for encryption and authentication of messages. It uses HKDF ( with SHA-256) for ke y derivation exten- sively . There isn’t a global PKI; instead, users verify each other’s identity keys out-of-band ( scanning QR codes or comparing ngerprints). This guards against MitM but relies on users to do verication. The identity keys are Ed25519 key pairs (since Ed25519 keys can b e the same as Curve25519 keys through a mapping, Signal uses the Curve25519 ke y also as an Ed25519 signing key to sign the pre-key). Quantum safety . Partially . Signal provides forward se crecy – once a message is delivered and keys ratchet forward, even if someone somehow got your current keys, they can’t decrypt old messages. Howev er , against a quantum threat, the long-term and ephemeral keys are all ECC (Curve25519, Ed25519). A quantum at- tacker who records the initial handshake (the X3DH key exchange messages) could break the Cur ve25519 Die–Hellman and the Ed25519 signature (if tr ying active attack) and obtain the master secret that bootstraps the conversation. With that, they could de- crypt all messages of that session ( assuming they also recorded the ciphertexts). So the condentiality of conversations is at risk if an adversary can harvest the key exchange data. This is analogous to TLS’s vulnerability . Every message round uses Curve25519 DH for the ratchet step. Those DH exchanges are ephemeral and last only one step , but a quantum attacker who records them and later breaks them could link some part of the key ev olution or possibly de crypt a particular message if they also had the relevant chain key state. Howev er , be- cause each DH is used to mix into a symmetric chain, breaking one ratchet step might only allow decrypting from that point onward (and not backward) – still a problem, but the design limits damage. Regardless, those DH steps are not quantum-safe either . The message encryption (AES-256, HMA C-SHA256) is ne un- der quantum assumptions (AES-256 is str ong, HMAC-SHA256 is okay , though SHA -256’s collision resistance is not critical here and Grover’s algorithm isn’t practical at scale). If users verify ngerprints in person, that part is safe (it’s a human trust link). But if an attacker could forge an identity key signature, they might try to impersonate a user to someone who hasn’t veried (a quantum attacker could fake the Ed25519 signature on a malicious pre-key to perform a MitM if the users don’t verify identity ngerprints) PQC migration eorts: In late 2023, the Signal team announced and started deploying an upgrade to the protocol called PQXDH (Post-Quantum Extended Die–Hellman). PQXDH augments the X3DH handshake by incorporating a p ost-quantum key agreement. Specically , Signal added CRYST ALS-K yber (K yb er1024) as a KEM alongside the existing X25519 exchange[ 44 ]. In practice, when two Signal clients establish a session, they perform the normal elliptic- curve X3DH and additionally perform a K yber encapsulation to the recipient’s static PQ public ke y . The two resulting shared secrets Study of Post antum status of Widely Used Protocols Conference acronym ’XX, June 03–05, 2018, W o odstock, N Y (one ECDH, one PQKEM) are combined (concatenated and hashed) to derive the session master key . This means an eavesdropper would need to break both the ECDH and the K yber KEM to recover the key . Breaking just one ( even the weak ECDH) is not enough. PQXDH handshake is already implemented in the latest Sig- nal clients (as of late 2023) and is being gradually enabled. Once both parties in a chat have updated to a PQXDH-capable version, new sessions they start will use the hybrid PQ handshake. After a sucient upgrade period, Signal plans to require PQXDH for all new chats, fully deprecating the old X3DH. This is one of the rst real-world deployments of post-quantum cryptography at the end-to-end application layer . PQ for message signatures: Signal doesn’t use message-level sig- natures (the protocol uses HMA C for authentication of messages, tied to the symmetric keys). So there isn’t an immediate need for a PQ digital signature in each message . The main signature use is the Ed25519 on the signe d pre-key which establishes one’s identity key authenticity . That could b e swapped out for a PQ signatur e (e .g. Dilithium) if needed in the future. But since that signature is only used to prevent an attacker from feeding a fake pre-key (a form of MitM), and since users are encouraged to verify keys out of band, the priority was clearly the condentiality via PQXDH. Early system-level analyses by Bobrysheva et al.[ 11 , 12 ] estab- lished that Signal’s quantum vulnerability lies specically in its Die–Hellman comp onents — X3DH initialization and the DH ratchet — while its symmetric primitives ( AES, HKDF) remain com- paratively robust under Grover-adjusted assumptions. They further argued that messaging systems provide a practical testbed for PQ deployment and pr opose d replacing DH/X3DH with isogeny-based schemes such as SIKE, identifying integration issues around au- thentication and associated data binding. Moving from feasibility to cryptographic structure, Brendel et al.[ 16 ] demonstrated that naively substituting DH with a p ost-quantum KEM breaks X3DH’s security guarante es b ecause asynchronous pr ekey r euse is not natu- rally supported by standard KEM se curity models; they introduced the abstraction of split KEMs to captur e the reuse and encapsula- tion patterns required by Signal. Building on this structural insight, Dobson and Galbraith[ 27 ] developed a formal Signal-spe cic AKE model and propose d SI-X3DH, a SIDH-based construction that preserves asynchronous key agreement while addressing adaptive static-key attacks. Finally , Brendel et al.[ 15 ] advanced the transi- tion further by constructing a fully post-quantum asynchronous deniable key exchange (SPQR), combining KEM-based agreement with designated-verier authentication to retain Signal’s core prop- erties — for ward se crecy , break-in recovery , exposure resilience, and deniability — under quantum-capable adversaries. Challenges. The main challenges in this transition stem from the structural properties that make Signal powerful: asynchronous key establishment, semi-static prekeys, deniability , and strong expo- sure resilience. Most PQ KEMs are not naturally secure under key reuse patterns required by X3DH, and isogeny-based approaches in- troduce concerns about adaptive attacks and validation complexity . Preserving deniability further complicates matters, since standard PQ signature schemes can produce transferable proofs of commu- nication, conicting with Signal’s goals. Additionally , integrating PQ primitives aects message size, au- thentication binding, and protocol state management, especially when replacing X3DH while maintaining compatibility with the Double Ratchet’s key derivation chains. Any PQ redesign must simultaneously satisfy quantum resistance, r euse safety , authentica- tion guarantees, and asynchronous usability—making the transition a delicate cryptographic and systems-level balancing act rather than a straightforward algorithm upgrade. 4 Conclusion This survey examined nine protocols that collectively secure the majority of Internet communication and found the post-quantum transition at varying stages of maturity . Hybrid key exchange using compact KEMs like ML-KEM has reached production deployment in TLS and Signal, demonstrating that post-quantum condential- ity is achievable to day with minimal p erformance penalty . How- ever , authentication remains a harder problem across the board —post-quantum signatures are larger , certicate chains inate sub- stantially , and existing trust infrastructures from the W eb PKI to DNSSEC and RPKI were not designed to accommo date them. Protocols that are tightly constrained by message size, such as DNSSEC and BGP, face structural obstacles that may require archi- tectural changes rather than algorithm substitution alone. Mean- while, application-layer pr oto cols like OpenID Connect introduce a distinct challenge: their security depends not only on transport protection but on the integrity of signed tokens and federated trust models that must themselves be migrated. With NIST targeting deprecation of quantum-vulnerable algorithms by 2030 and full retirement by 2035, the window for planning and executing this transition is narrowing. Organisations should begin now by inven- torying their cryptographic dep endencies, deploying hybrid modes where available, and tracking the standardisation eorts that will determine how each protocol ultimately achiev es quantum resis- tance. References [1] Alnaha wi, N., Müller, J., Oupick ` y, J., and Wiesmaier, A. A comprehensive survey on post-quantum tls. IA CR Communications in Cr yptology (2024). [2] Amazon Web Services . A ws libcrypto, 2023. Accessed: 2024-08-22. [3] Aragon, N., Gaborit, P., Haute, T., and Zemor, G. Bike: Bit-ipping key encapsulation. In PQCrypto 2021: Post-Quantum Cryptography (2021), Springer , pp. 1–22. [4] Bae, S., Chang, Y., P ark, H., Kim, M., and Shin, Y. A performance evaluation of ipsec with post-quantum cryptography . In International Conference on Information Security and Cryptology (2022), Springer , pp. 249–266. [5] Benčina, B., Dowling, B., Maram, V ., and Xaga w a, K. Post-quantum crypto- graphic analysis of ssh. In 2025 IEEE Symposium on Security and Privacy (SP) (2025), IEEE, pp. 595–613. [6] Bernstein, D. J., Brumley, B. B., Chen, M.-S., and Tuveri, N. { OpenSSLN TRU } : Faster post-quantum { TLS } key exchange. In 31st USENIX security symposium (USENIX Security 22) (2022), pp. 845–862. [7] Bernstein, D. J., Hülsing, A., Kölbl, S., Niederhagen, R., Rijneveld, J., and Schw abe, P. The sphincs+ signature framework. In Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security (New Y ork, NY, USA, 2019), CCS ’19, Association for Computing Machinery , p. 2129–2146. [8] Bernstein, D. J., Lange, T ., and Others . libpqcr ypto: Post-quantum crypto- graphic library from the pqcrypto project. https://libpqcrypto.org, 2018. Accessed: 2025-09-30. [9] Blanchet, B., and Jacomme, C. Post-quantum sound cryptoverif and verica- tion of hybrid tls and ssh key-exchanges. In 2024 IEEE 37th Computer Security Foundations Symposium (CSF) (2024), IEEE, pp. 543–556. [10] Blanco-Romero, J., García, P. O ., Sobral-Blanco, D., Mendoza, F. A., V ilas, A. F., and Fernández-Veiga, M. Hybrid quantum security for ipsec. arXiv preprint arXiv:2507.09288 (2025). [11] Bobryshev a, J., and Zapechnik ov, S. Post-quantum security of communication and messaging protocols: achievements, challenges and new perspectives. In Conference acronym ’XX, June 03–05, 2018, W o odstock, N Y T ushin Mallick, Ashish Kundu, and Ramana Kompella 2019 IEEE Conference of Russian Y oung Researchers in Electrical and Electronic Engineering (EIConRus) (2019), IEEE, pp. 1803–1806. [12] Bobryshev a, J., and Zapechnikov, S. Post-quantum security of messaging protocols: analysis of double ratcheting algorithm. In 2020 IEEE Conference of Russian Y oung Researchers in Electrical and Electronic Engineering (EIConRus) (2020), IEEE, pp. 2041–2044. [13] Bos, J. W ., Costello, C., Naehrig, M., and Stebila, D. Frodo: T ake o the ring! practical, quantum-secure key exchange from lwe. In Procee dings of the 2016 ACM SIGSAC Conference on Computer and Communications Security (2016), pp. 1006–1018. [14] Bos, J. W ., Ducas, L., Kiltz, E., Lepoint, T ., Lyubashevsky, V ., Schanck, J., Schw abe, P., Seiler, G., and Stehlé, D . Crystals-kyber: A cca-secure module- lattice-based kem. In 2018 IEEE European Symposium on Security and Privacy (EuroS&P) (2018), IEEE, pp. 353–367. [15] Brendel, J., Fiedler, R., Günther, F., Janson, C., and Stebila, D. Post-quantum asynchronous deniable key exchange and the signal handshake. In IACR Interna- tional Conference on Public-Key Cryptography (2022), Springer , pp. 3–34. [16] Brendel, J., Fischlin, M., Günther, F ., Janson, C., and Stebila, D. T owards post-quantum security for signal’s x3dh handshake. In International Conference on Selected Areas in Cr yptography (2020), Springer , pp. 404–430. [17] Buchmann, J., Dahmen, E., and Hülsing, A. Xmss: A practical forward se- cure signature scheme based on minimal security assumptions. In International W orkshop on Post-Quantum Cryptography (2011), Springer , pp. 117–129. [18] Bürstingha us-Steinbach, K., Kra uss, C., Niederhagen, R., and Schneider, M. Post-quantum tls on embedded systems: Integrating and evaluating kyber and sphincs+ with mbed tls. In Proceedings of the 15th ACM Asia Conference on Computer and Communications Security (2020), pp. 841–852. [19] Chase, M., Derler, D., Goldfeder, S., Katz, J., K olesnikov, V ., Orlandi, C., Ramacher, S., Rechberger, C., Slamanig, D., W ang, X., and Zaverucha, G. The picnic digital signature algorithm. Presentation at the Second NIST PQC Standardization Conference, A ug. 2019. Accessed: 2026-02-12. [20] Cloudflare . The post-quantum internet is coming. https://blog.cloudare.com /pq- 2024/, 2024. Accessed: 2025-05-19. [21] Crockett, E., P aqin, C., and Stebila, D. Prototyping post-quantum and hybrid key exchange and authentication in tls and ssh. Cryptology ePrint Archive (2019). [22] D’ Anvers, J.-P., Guo, Q., Johansson, T ., Nilsson, E., Verca uteren, F., and Verba uwhede, I. Saber: Module-lwr based key exchange , cpa-secure encryption and cca-secure kem. In International Conference on Cryptographic Hardware and Embedded Systems (2018), Springer , pp. 282–305. [23] deSEC, and Po werDNS . More pqc in powerdns: A dnssec eld study . Accessed: 2025-05-19. [24] Developers, O . Patch for hybrid pq-tls key exchange in openvpn. h t t p s : //patchwork.openvpn.ne t/project/openvpn2/p atch/400a4652- 39d6- e c8d- 6f 58- 824f 552e0440@baentsch.ch/, 2022. Accessed: 2025-05-19. [25] Developers, P. Pqclean: Clean, portable implementations of post-quantum cryptography . https://github.com/PQClean/PQClean, 2022. Accessed: 2025-09- 30. [26] Ding, J., and Schmidt, D. Rainbow: A new multivariable polynomial signature scheme. In International Conference on A pplied Cryptography and Network Security (2005), Springer , pp. 164–175. [27] Dobson, S., and Galbraith, S. D. Post-quantum signal key agreement from sidh. In International Conference on Post-Quantum Cryptography (2022), Springer, pp. 422–450. [28] Doesburg, D. Post-quantum cr yptography for the rpki. Master’s thesis. Radboud University (2025). [29] Dong, B., and W ang, Q. Epquic: Ecient post-quantum cryptography for quic- enabled secure communication. In Proceedings of the Great Lakes Symposium on VLSI 2025 (2025), pp. 141–146. [30] Faz-Hernandez, A., and Kwia tkowski, K. Introducing CIRCL: A n Advanced Cryptographic Library . Cloudare, June 2019. A vailable at https://github.com/clo udare/circl. v1.4.0 Accessed A ug, 2024. [31] Gaborit, P., Aguilar-Melchor, C., Ara gon, N., Bett aieb, S., Bidoux, L., Blazy, O., Deneuville, J.-C., Persichetti, E., Zémor, G., Bos, J., Dion, A., Lacan, J., Robert, J.-M., Véron, P ., Barreto, P. L., Ghosh, S., Gueron, S., Güneysu, T ., Misoczki, R., Richter-Brokmann, J., Sendrier, N., Tillich, J.-P., and V asseur, V . Hamming quasi-cyclic (hqc) specications. Specication, HQC Team, A ug. 2025. Accessed: 2026-02-12. [32] Gazdag, S.-L., Grundner-Culemann, S., Heider, T ., Herzinger, D., Schärtl, F., Cho, J. Y ., Guggemos, T ., and Loebenberger, D. Quantum-resistant macsec and ipsec for virtual private networks. In International Conference on Research in Security Standardisation (2023), Springer , pp. 1–21. [33] Goertzen, J., and Stebila, D . Post-quantum signatures in dnssec via request- based fragmentation. In International Conference on Post-Quantum Cr yptography (2023), Springer , pp. 535–564. [34] Gonzalez, R., and Wiggers, T . Kemtls vs. post-quantum tls: Performance on embedded systems. In International Conference on Security, Privacy, and A pplied Cryptography Engineering (2022), Springer, pp . 99–117. [35] Group, I. C. W . Post-quantum signature algorithms for cose. h tt p s: / /d a t at r ac ke r . ie tf . o rg /d oc /h tm l/ dr af t - ie tf - co se- p ost - qua nt um - si gn at ur es- 01, 2024. Internet-Draft. [36] Group, I. T . W . Hybrid key exchange in tls 1.3. https://datatracker .ietf .org/doc/h tml/draf t- ietf - tls- hybrid- design- 12, 2024. Internet-Draft. [37] Group, I. T . W . Support for ml-kem in tls 1.3. https://datatracker .ietf .org/doc/h tml/draf t- ietf - tls- mlkem- 00, 2024. Internet-Draft. [38] Herzinger, D., Gazdag, S.-L., and Loebenberger, D. Real-world quantum- resistant ipsec. In 2021 14th International Conference on Security of Information and Networks (SIN) (2021), vol. 1, IEEE, pp. 1–8. [39] Hoffstein, J., Pipher, J., and Sil verman, J. H. Ntru: A ring-based public key cryptosystem. In International Algorithmic Number Theor y Symposium (1998), Springer , pp. 267–288. [40] Jao, D ., Azarderakhsh, R., Campagna, M., Costello, C., De Feo, L., Hess, B., Hutchinson, A., Jalali, A., Karabina, K., Koziel, B., LaMa cchia, B., Longa, P., Naehrig, M., Pereira, G., Renes, J., Soukharev, V ., and Urbanik, D. Su- persingular isogeny key encapsulation (sike) specication. Specication, SIKE T eam, Sept. 2022. Accessed: 2026-02-12. [41] Josefsson, S. Post-quantum hybrid key exchange for ssh. https://datatracker .ie tf .org/doc/draft- josefsson- ntruprime- ssh/, 2023. Internet-Draft. [42] Kempf, M., Gauder, N., Jaeger, B., Zirngibl, J., and Carle, G. A quantum of quic: Dissecting cryptography with post-quantum insights. In 2024 IFIP Networking Conference (IFIP Networking) (2024), IEEE, pp. 195–203. [43] Kivinen, T ., and Smyslov, V . Multiple Key Exchanges in IKEv2. RFC 9370, Mar. 2023. RFC 9370. [44] Kret, E., and Schmidt, R. PQXDH: The post-quantum extended die–hellman key agreement protocol. Specication Revision 3, Signal Foundation, Jan. 2024. Last updated January 23, 2024. [45] La wo, D. C., Abu Bakar, R., Cano Aguilera, A., Cugini, F., Imaña, J. L., T afur Monroy, I., and Vegas Olmos, J. J. Wireless and ber-based post- quantum-cryptography-secured ipsec tunnel. Future Internet 16 , 8 (2024), 300. [46] McEliece, R. J. A public-key cryptosystem based on algebraic co ding theory . In The Deep Space Network Progress Report (1978), vol. 44, pp. 114–116. [47] McGow an, C., Liu, J., and Ruj, S. Se curity considerations for post-quantum signatures in dnssec via request-based fragmentation. In Companion Proceedings of the ACM on W eb Conference 2025 (2025), pp. 1189–1193. [48] Miesch, K., Schulmann, H., and V ogel, N. Poster: The rocky road towards rpki algorithm agility . In Proceedings of the 2025 ACM SIGSAC Conference on Computer and Communications Security (2025), pp. 4767–4769. [49] Montenegro, J. A., Rios, R., and Bonilla, J. Comparative analysis of post- quantum handshake performance in quic and tls protocols. Computer Networks (2025), 111957. [50] Müller, M., de Jong, J., v an Heesch, M., Overeinder, B., and v an Rijswijk- Deij, R. Retrotting post-quantum cryptography in internet protocols: a case study of dnssec. ACM SIGCOMM Computer Communication Review 50 , 4 (2020), 49–57. [51] Murphy, S., P a tel, K., W ard, D ., and Bush, R. BGPsec Algorithms, Key Formats, and Signature Formats. RFC 8608, June 2019. RFC 8608. [52] Na tional Institute of St andards and Technology (NIST) . Fips 204: Module- lattice-based digital signature standard, A ug. 2024. A vailable at https://doi.org/ 10.6028/NIST.FIPS.204. [53] Na tional Institute of Stand ards and Technology (NIST) . PQC: Post- Quantum Cryptography , 2024. A vailable at https://csrc.nist.gov/projects/post- quantum- cryptography. [54] Na tional Institute of St andards and Technology (NIST) . FIPS 203 Module- Lattice-Based Key-Encapsulation Mechanism Standard, A ugust 13, 2024. A vail- able at https://csrc.nist.gov/pubs/f ips/203/nal. [55] Na tional Institute of St andards and Technology (NIST) . FIPS 204 Module- Lattice-Based Digital Signature Standard, August 13, 2024. A vailable at ht tps : //csrc.nist.gov/pubs/f ips/204/nal. [56] Na tional Institute of St andards and Technology (NIST) . FIPS 205 Stateless Hash-Based Digital Signature Standard, August 13, 2024. A vailable at h tt p s : //csrc.nist.gov/pubs/f ips/205/nal. [57] Na tional Institute of St andards and Technology (NIST) . NIST Releases First 3 Finalized post-quantum Post-Quantum Encr yption Standards, August 13, 2024. Available at htt ps:/ /w ww . nist .gov /new s- event s/ne ws/2 024 /08/ nist- releases- rst- 3- nalized- post- quantum- encryption- standards. [58] Na tional Institute of St andards and Technology (NIST) . FIPS 203 (initial public draft), Module-Lattice-Based Key-Encapsulation Mechanism Standard, August 24, 2023. [59] Na tional Institute of St andards and Technology (NIST) . FIPS 204 (initial public draft), Module-Lattice-Based Digital Signature Standard, August 24, 2023. [60] Na tional Institute of St andards and Technology (NIST) . FIPS 205 (initial public draft), Stateless Hash-Based Digital Signature Standard, A ugust 24, 2023. [61] NIST . Bgp secure routing e xtension (bgp-sr x). https://www .nist.gov/servic es- resources/software/bgp- secure- routing- extension- bgp- srx- software- suite, 2023. Accessed: 2025-05-19. [62] NIST . Brite: Bgpsec-rpki interoperability test and evaluation system. https://w w w .nist.gov/services- resources/software/brite- bgpsec- rpki- interoperability- test- Study of Post antum status of Widely Used Protocols Conference acronym ’XX, June 03–05, 2018, W o odstock, N Y evaluation- system, 2023. Accessed: 2025-05-19. [63] Open antum Safe Project . libo qs: Open Quantum Safe project, 2021. A vail- able at https://github.com/open- quantum- safe/liboqs. [64] Ounsworth, M., Gra y, J., P ala, M., Kla ussner, J., and Fluhrer, S. Composite ML-DSA for use in X.509 Public Key Infrastructure. Internet-Draft draft-ietf- lamps-pq-composite-sigs-15, Internet Engineering T ask Force, Feb. 2026. W ork in Progress. [65] P an, S. W . S., Nguyen, D. D. N., Doss, R., Armstrong, W ., Ga urav aram, P., et al. Double-signe d fragmented dnssec for countering quantum threat. arXiv preprint arXiv:2411.07535 (2024). [66] P a qin, C., Stebila, D ., and T amv ada, G. Benchmarking post-quantum cryptog- raphy in tls. In International Conference on Post-Quantum Cr yptography (2020), Springer , pp. 72–91. [67] Perret, L., Casanov a, A., Faugère, J.-C., Macario-Ra t, G., P a t arin, J., and Ryckeghem, J. Gemss: A great multivariate short signature. Presentation at the Second PQC Standardization Conference, A ug. 2019. Accessed: 2026-02-12. [68] PQClean and PQM4 Teams . PQM4: Post-quantum cryptography for cortex-m4, 2021. Available at https://github.com/mupq/pqm4. [69] Qi, M., and Chen, C. Hpqke: Hybrid post-quantum key exchange protocol for ssh transport layer from csidh. IEEE Transactions on Information Forensics and Security (2025). [70] Raa vi, M., Wuthier, S., Chandramouli, P., Zhou, X., and Chang, S.-Y. Quic protocol with post-quantum authentication. In International Conference on Infor- mation Security (2022), Springer, pp . 84–91. [71] Raa vi, M., Wuthier, S., Zhou, X., and Chang, S.-Y. Post-quantum quic pro- tocol in cloud networking. In 2023 Joint European Conference on Networks and Communications & 6G Summit (EuCNC/6G Summit) (2023), IEEE, pp. 573–578. [72] Ra w at, A. S., and Jhanw ar, M. P. Post-quantum dnsse c over udp via qname- based fragmentation. In International Conference on Security, Privacy , and A pplied Cryptography Engineering (2023), Springer, pp . 66–85. [73] Ra w a t, A. S., and Jhanw ar, M. P. Post-quantum dnssec with faster tcp fallbacks. In International Conference on Cryptology in India (2024), Springer , pp. 212–236. [74] Ra w at, A. S., and Jhanw ar, M. P. Quantum-safe signatureless dnsse c. In Proceedings of the 20th ACM Asia Conference on Computer and Communications Security (2025), pp. 267–282. [75] Research, M. Post-quantum vpn project on github. https://github.com/microso ft/PQCrypto- VPN, 2022. Accessed: 2025-05-19. [76] Rigon, P., Fu, H., Cordeiro, W ., and Fung, C. Comprehensive post-quantum cryptography performance e valuations for quic protocol. In 2025 IEEE Conference on Communications and Network Security (CNS) (2025), IEEE, pp. 1–9. [77] Schardong, F., Giron, A. A., Müller, F. L., and Custódio, R. Post-quantum electronic identity: Adapting openid connect and oauth 2.0 to the post-quantum era. In Cryptology and Network Security (Cham, 2022), A. R. Beresford, A. Patra, and E. Bellini, Eds., Springer International Publishing, pp. 371–390. [78] Schutijser, C., Koning, R., Lastdrager, E., and Hesselman, C. Evaluating post-quantum cryptography in dnssec signing for top-level domain operators. In 2025 9th Network Trac Measurement and A nalysis Conference (TMA) (2025), IEEE, pp. 1–10. [79] Schw abe, P ., Stebila, D., and Wiggers, T . Post-quantum tls without handshake signatures. In Proceedings of the 2020 ACM SIGSAC conference on computer and communications security (2020), pp. 1461–1480. [80] Sikeridis, D., Kamp anakis, P., and Devetsikiotis, M. Assessing the overhead of post-quantum cr yptography in tls 1.3 and ssh. In Proce e dings of the 16th International Conference on emerging Networking EXperiments and T echnologies (2020), pp. 149–156. [81] Sikeridis, D., Kamp anakis, P., and Devetsikiotis, M. Post-quantum authenti- cation in tls 1.3: A performance study . Cryptology ePrint Ar chive (2020). [82] Sosnowski, M., W iedner, F., Ha user, E., Steger, L., Schoinianakis, D., Gal- lenmüller, S., and Carle, G. The performance of post-quantum tls 1.3. In Companion of the 19th international conference on emerging networking experi- ments and technologies (2023), pp. 19–27. [83] Tran, D. D., Oga t a, K., Escobar, S., Akleylek, S., and Otmani, A. Formal analysis of post-quantum hybrid key exchange ssh transport lay er protocol. IEEE Access 12 (2023), 1672–1687. [84] Tw ardokus, G., Joslin, W ., Rahbari, H., and La yton, W . Assessing the viability of quantum-resistant ikev2 over constraine d and internet-scale networks. In Proceedings of the 2025 Quantum Security and Privacy W orkshop (New Y ork, NY, USA, 2025), QSec ’25, Association for Computing Machinery , p. 28–33. [85] W outers, P., Nir, Y ., Kivinen, T ., and Miga ul t, D. Adding Support for External Pre-Shared Ke ys (PSKs) to IKEv2. RFC 8784, May 2020. RFC 8784.