NoisePQC++: A Unified NIST-Compliant PQC and Hybrid-PQC Implementation of the Noise Protocol Author’s Accepted Manuscript Nadeem Ahmed Aryya Gangopadhyay Lei Zhang Department of Information Systems, University of Maryland Baltimore County, Baltimore, USA {nahmed5, gangopad, leizhang}@umbc.edu
Abstract
arXiv:2608.00954v1 [cs.CR] 2 Aug 2026
The threat of quantum computers to classical public-key cryptography has created an urgent need to evolve secure communication protocols with post-quantum cryptographic (PQC) primitives. The Noise Protocol Framework, widely used in systems such as WireGuard and WhatsApp, traditionally relies on the Elliptic Curve Diffie-Hellman (ECDH) public-key exchange scheme, which is vulnerable to quantum threats. In this paper, we present NoisePQC++, a unified C++23 implementation of the Noise Protocol framework augmented with post-quantum Key Encapsulation Mechanisms and Hybrid Forward Secrecy. Our design integrates the National Institute of Standards and Technology (NIST) standardized ML-KEM algorithm alongside classical ECDH, enabling full PQC, hybrid ECDH+PQC handshakes, and unified support for all 57 classical Noise handshake pattern variants, 13 post-quantum Noise handshakes, and their hybrid variants. Compared with prior work, NoisePQC++ offers broader protocol coverage, more complete implementation support, and greater flexibility. Our evaluation shows minimal overhead under normal network conditions and acceptable overhead in adverse cases, while significantly improving resistance against quantum adversaries. These results indicate that NIST-standardized post-quantum and hybrid Noise handshakes are practical and provide a credible basis for future deployment.
Keywords post-quantum cryptography, secure protocols, quantum threats, noise protocol framework Accepted for publication at the IEEE International Conference on Quantum Computing and Engineering (QCE 2026). © 2026 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.
1
Introduction
The Noise Protocol Framework [1] provides a concise and flexible method for specifying Authenticated Key Exchange (AKE) protocols using Symmetric and Asymmetric Cryptography. Due to its simplicity, efficiency, and strong security foundation, the Noise Protocol Framework underpins the security of a variety of software systems, such as WireGuard, Lightning, and WhatsApp [1]. The framework is often viewed as a lightweight, pattern-driven approach to build secure channels similar to Transport Layer Security (TLS) in application-specific deployments because it exposes a compact language to describe AKE and transport protection [2]. Noise is also related to the Signal [3] family of secure messaging designs through the shared design lineage: while it is not itself a ratcheting protocol, the official Noise specification explicitly cites the Key Derivation Function (KDF) chains used in the Double Ratchet Algorithm as an influence on its design [1]. This reliance on classical ECDH also creates a long-term risk: sufficiently powerful quantum computers could undermine algorithms such as X25519 and X448 by weakening the hardness of the underlying discrete logarithm problem [4]. This has motivated efforts to extend Noise with post-quantum cryptography (PQC), particularly Key Encapsulation Mechanisms (KEMs), either replacing or augmenting ECDH [5, 6]. Prior work [7–10] has demonstrated that post-quantum and hybrid extensions of Noise are feasible, but existing implementations remain limited in pattern coverage, hybrid support, or overall completeness. A detailed comparison of these efforts is provided in Section 2.4 and Table 2. In this work, we bridge this gap and advance the existing Noise Protocol with five main contributions. First, we present NoisePQC++, a C++23 implementation of the Noise Protocol Framework spanning classical, post-quantum, and hybrid handshakes within one unified architecture. Second, the im-
plementation supports all 57 classical Noise handshake pattern variants, all 13 published PQNoise [7] patterns, and systematic hybrid ECDH+PQC [11] variants, providing broader coverage than prior implementations. Third, our implementation integrates the National Institute of Standards and Technology (NIST) standardized ML-KEM [12] algorithm at three security levels (ML-KEM-512, ML-KEM-768, and ML-KEM-1024), in conjunction with classical ECDH, within a unified handshake engine. Fourth, it provides practical engineering support for cross-platform builds, instrumentation, and application-level integration, as well as developer-oriented capabilities including parsing utilities, examples, and comprehensive testing infrastructure. Fifth, we evaluate the practicality of these designs through initial benchmarking, showing that post-quantum and hybrid Noise handshakes remain feasible with manageable overhead. To our knowledge, NoisePQC++ provides one of the most complete and flexible PQC-capable Noise Protocol reference implementations currently available. The remainder of this paper reviews the background and related work in Section 2, presents the design, methodology, and architecture of NoisePQC++ in Sections 3, 4 and 5, evaluates its correctness and performance in Section 6, and concludes with future directions in Section 7.
2
Background and Related Work
2.1
Noise Protocol Framework and ECDH Handshakes Noise is a framework for constructing secure channel protocols from simple cryptographic building blocks. At its core, a Noise handshake pattern is a predefined sequence of message exchanges carrying public keys or ciphertexts [13]. The allowed tokens in Noise handshake patterns include: • e (Ephemeral DH public key): A party generates a new ephemeral key pair and sends the public key.
• s (Static DH public key): A party sends its static (long- tion (decapsulation), rather than both performing a symmetric term) public key, often after encrypting it under an operation as in ECDH [35]. ephemeral-derived key. CRYSTALS-Kyber, standardized by NIST as ML-KEM (Module-Lattice KEM) in FIPS 203, is a lattice-based KEM • ee , es , se , ss (DH operations): These tokens denote whose security is based on the Module-LWE problem, which DH computations between the initiator’s and responis believed to be resistant to quantum attacks [12]. ML-KEM der’s key shares, where the first letter refers to the initiais available in parameter sets that offer security roughly equivtor, the second to the responder, e denotes ephemeral, alent to classical 128-bit, 192-bit, and 256-bit levels, namely and s denotes static [13]. Thus, ee combines both ML-KEM-512, ML-KEM-768, and ML-KEM-1024 [12]. In ephemeral keys, es the initiator’s ephemeral with the NoisePQC++, we integrate all three parameter sets. Across the responder’s static, se the initiator’s static with the reML-KEM parameter sets collectively, public keys are approxisponder’s ephemeral, and ss both static keys. Each mately 800 to 1568 bytes, significantly larger than the elliptic DH result is mixed into the cryptographic state of the curve keys (32 to 56 bytes) and the corresponding KEM enhandshake. capsulation ciphertexts are about 768 to 1568 bytes. This size In a Noise handshake, both parties maintain a SymmetricState difference has implications for handshake message sizes and with two primary components: a chaining key (usually denoted network performance. However, ML-KEM’s computational effick ), which accumulates shared secrets to derive session keys, ciency is high: on modern CPUs it can encapsulate/decapsulate and a handshake hash ( h ), which accumulates transcript data to in tens of microseconds, comparable to or even faster than some provide context integrity, often referred to as channel binding. ECDH operations, meaning the computational overhead of using As each token is processed, new data is mixed into these states. ML-KEM in a handshake is relatively low. We present these At the end of the handshake, both parties derive symmetric results later in Section 6. secrets (e.g., encryption keys) from the final ck and h . If an adversary has not compromised participant secrets, the resulting 2.3 Hybrid Key Exchange Given the uncertainties in the long-term security of new session keys provide confidentiality and integrity for subsequent PQC schemes, combining classical and post-quantum methods transport messages [13]. Using these tokens, Noise defines 15 base patterns, including in hybrid modes is widely recommended by many organizations, interactive patterns such as NN, NK, NX, KN, KK, KX, XN, such as the Internet Engineering Task Force (IETF) and NIST, XK, XX, IN, IK, and IX, which cover different authentication during the transition to PQC [15, 16, 36]. A hybrid key exscenarios [13]. With one-way and pre-shared-key (PSK) modi- change means that the parties perform both a classical ECDH fiers, the Noise specification defines 57 variants. In these pattern exchange and a PQ KEM exchange, and then combine the two names, the first letter describes the initiator’s static key and the resulting shared secrets into one composite key. In this way, second the responder’s: N means no static key, K means the even if one of the schemes is later broken, the other (hopefully static key is already known to the peer, X means the static key still secure) scheme ensures that the session remains protected. is transmitted during the handshake, and I means the initiator In NoisePQC++, we implement hybrid handshakes as Hybrid sends its static key immediately in the first message, reducing Forward Secrecy (HFS) patterns, denoted by appending an identity hiding [13]. For example, the widely used XX pattern “hfs” suffix to a base pattern. For example, XXhfs is the hybrid is a three-message handshake in which the initiator sends an variant of XX, which performs both an X25519 ECDH and an ephemeral key, the responder replies with its ephemeral key ML-KEM encapsulation within the same handshake. Our imand encrypted static public key, and the initiator then sends its plementation follows the approach of the specifications of the encrypted static public key, with multiple ECDH operations KEM-based Hybrid Forward Secrecy in Noise Protocol, as well mixed into the handshake state. All Noise patterns use ECDH as Renckens et al. (2024) and related work [8, 11]. as the only public-key primitive, commonly X25519 for 128-bit security or X448 for 224-bit security. The security of Noise 2.4 Related Work Prior work established the foundations for post-quantum handshakes is well studied under strong models, assuming the extensions of the Noise framework, but existing efforts remained hardness of the DH problem [14]. The flexibility of the framelimited in scope, implementation maturity, or feature coverage. work comes from the support of different patterns and cryptographic primitives, including ECDH curves, symmetric ciphers, 2.4.1 Foundational PQ Noise Designs and Implementations and hash functions, while preserving a unified state-machine Post-quantum Noise was first formalized by Yawning Anmodel and security properties. gel et al. in Post-Quantum Noise, which introduced a generic method for converting classical Noise patterns into PQ variants 2.2 Post-Quantum Cryptography by replacing DH operations with KEM-based constructions [7]. Post-quantum cryptography refers to cryptographic algo- Their analysis established a comparable security notion under rithms believed to be secure against quantum computer at- the IND-CCA-secure KEM assumptions, and they released an tacks [4]. In the context of key exchange, the primary PQC experimental prototype by extending the Go-based nyquist liprimitive is the KEM [12]. A KEM is a public-key encryption brary [17]. However, that implementation remained a proof of scheme optimized for deriving a shared secret. One party gen- concept, focused primarily on pure PQ handshakes, and did not erates a random secret and encapsulates it to the other party’s provide integrated hybrid ECDH+KEM support. Subsequent impublic key, producing a ciphertext. The other party decapsulates plementation work, most notably Clatter in Rust, advanced this this ciphertext with its private key to recover the secret. Both line by supporting PQNoise patterns as well as hybrid construcparties then share this secret, which can serve as a key for sym- tions [9]. Clatter emphasized memory safety, correctness, and metric encryption. The crucial difference from ECDH is that embedded suitability through pure Rust support, and followed with a KEM, only the sender performs public-key encryption Noise revision 34. At the same time, its design intentionally (encapsulation) and the receiver performs a private-key opera- narrowed scope: it supports only X25519 for classical ECDH, 2
omits X448 as well as deferred and fallback patterns, and does not implement the standard Noise pattern-string parser. Instead, handshakes are instantiated programmatically, which reduces flexibility for dynamic negotiation. Thus, while Clatter demonstrates a practical PQ-capable Noise library, it does not attempt full pattern or tooling coverage.
3.2
Leverage of Existing Crypto Primitives Implementing cryptography correctly is difficult. We rely on the Botan cryptographic library [19] as our underlying crypto provider for all operations: symmetric ciphers, hash functions, ECDH, and KEM. Botan is a well-established C++ library with constant-time implementations and has already included NISTstandardized PQC algorithms. The choice of using Botan as our cryptographic backend is derived from our previous work, which surveyed the main open-source cryptographic libraries for their support of PQC [20]. By using Botan, we offload low-level crypto details (e.g., field arithmetic for X25519 or lattice math for ML-KEM) to a vetted source. This allowed us to focus on the protocol integration logic. It also simplifies cross-platform support, as Botan contains optimized routines for various architectures (using AES-NI, AVX2, etc. when available) [19]. Our build system includes only the absolute minimal cryptographic primitive modules from the latest stable Botan 3 release for all target platforms (Windows x64, Linux x64/ARM, macOS x64/ARM) [21] and, once compiled as its own static library by the build system, we invoke Botan via its C++ API inside NoisePQC++.
2.4.2 Performance Studies and Related Hybrid Efforts Renckens et al. further examined the practicality of PQ and hybrid Noise by extending the noise-c reference implementation with ML-KEM-512 and hybrid variants of the fundamental interactive Noise patterns [8]. Their experiments on laptop and embedded ARM platforms showed that under typical network conditions, the latency differences between classical Noise and PQNoise are small because network delay dominates cryptographic cost. Overhead became more visible under elevated packet loss, where the larger PQ public keys and ciphertexts increased retransmission costs. They also found that hybrid X25519+ML-KEM exchanges impose only modest additional cost when no extra round trips are introduced. Although this work demonstrated feasibility, the resulting code remained research-oriented, limited to a single KEM and a restricted subset of patterns. Related efforts include experimental post-quantum extensions of WireGuard [18], effectively applying hybrid concepts to the Noise IK pattern, as well as Katzenpost’s HPN library [10], which explored combining multiple KEMs within one design. These efforts further illustrate practical and research interest in hybrid Noise-style protocols, but they likewise do not provide a broad, unified, developer-oriented implementation of the full Noise design space.
3.3
Type Safety and Modularity We adopted modern C++23 features (especially modules and strong type enums) to create a clear separation of concerns in the code. Each higher-level NoisePQC++ cryptographic primitive is encapsulated in its own module ( Cipher , Hash , Dh/KEM ), and the handshake state machine operates on abstracted types (e.g., KeyPair or SharedSecret ) without needing to know the algorithm details. We defined enum classes for algorithm selections ( KeyAlgo , CipherAlgo , HashAlgo ) so that an invalid combination (like using a KEM where ECDH is required, or an unsupported algorithm name) can be caught at compile-time or initializationtime. Using C++ modules instead of traditional headers helps with encapsulation: internal implementation details of, say, MLKEM key sizes are hidden behind the Dh module, exposing only clean interfaces to the rest of the system.
2.4.3 Summary of Gaps Taken together, prior work demonstrated that PQ and hybrid Noise are both theoretically sound and practically viable. However, no earlier implementation combined broad Noise pattern coverage with the engineering features needed to move from a research prototype to a reusable software base: a unified classical/PQ/hybrid execution model, portability across platforms, and developer-focused capabilities such as parsing, instrumentation, and extensive testing. This makes NoisePQC++ more practical than prior efforts because the same codebase can be built, integrated, debugged, and evaluated across different environments without redesigning the protocol logic for each variant. It also makes the system useful as a research platform, since new patterns, KEM choices, fallback mechanisms, and application integrations can be studied within one consistent implementation rather than across disconnected prototypes.
3.4
Minimal Intrusion for PQ/HFS When adding PQ and HFS features, we aim to minimize changes to the established Noise protocol flow. The Noise symmetric state (the running handshake hash and chaining key) is used exactly as before; we simply mix in KEM-derived secrets using the same HMAC-based KDF (HKDF) MixKey operations that mix ECDH outputs. The order of mixing follows the pattern token order, so the transcript hash and chaining key evolve in a canonical way, whether a secret came from an 3 Design Goals and System Overview The development of the NoisePQC++ system design was ECDH or a KEM. For example, in a hybrid handshake, if the pattern dictates an ee (ECDH) followed by an ekem1 (KEM driven by a set of fundamental objectives: token, discussed in Section 5) in the same message, we call SymmetricState.MixKey(DH_shared) then MixKey(KEM_shared) in that 3.1 Unified Execution Model We decided early on that the same core state machine should sequence. This ensures that the final derived keys are a function handle classical, post-quantum, and hybrid handshakes. In con- of both secrets. We did not need to invent a new key combitrast to earlier approaches, instead of forking the codebase or nation function: the Noise HKDF chaining already serves to implementing separate handshake routines for PQ patterns, we “mix” multiple inputs serially, which effectively concatenates augment the Noise handshake logic with clear, well-defined ex- the entropy. This approach aligns with the recommendations for tensions for PQ. This ensures consistency and avoids redundant hybrid key combination (often an XOR or KDF combination) code. Concretely, we treat ECDH and KEM as two facets of a and has the advantage of staying within the proven design of generic “key exchange” interface, allowing them to plug into Noise [13, 36]. the handshake state machine interchangeably. The handshake pattern definition format was extended to include the new token 3.5 Instrumentation and Testing as First-Class Goals types ( ekem , skem , discussed in Section 5), but the parsing and From the outset, we intended to conduct thorough testing and execution engine remains unified. to offer clear insight into how the protocol operates internally. 3
We generated unit tests for each module and each variant of the handshake pattern (more than 200 tests with 500+ assertions in total) to verify the correctness. For classical patterns, we crosschecked against official Noise test vectors where available [22]. For PQ patterns, we validated that initiator and responder instances of the same pattern produce matching keys and that known-edge cases (like the wrong key or message reorder) trigger the expected errors. We also developed an instrumentation system, described later in Section 5, that can log handshake progress step by step. This dual focus on testing and logging influenced our methodology: for instance, we wrote the handshake execution logic in a way that could easily hook into logging callbacks at each token processing step, and we maintained a debug mode that parallels the release logic to ensure any divergence would be caught by tests.
Table 1: Notation used in the XXhfs handshake transcript.
Summary Using these objectives as our core guiding principles, we implemented NoisePQC++ in an iterative manner: first by implementing the classical Noise patterns, then adding KEM support in the Dh module, defining PQ patterns, and finally adding hybrid patterns once the PQ pieces were stable. At each stage, tests were used to confirm that adding new functionality did not break existing behavior (e.g., classical pattern tests continued to pass when PQ code was added, thanks to careful isolation of code paths when KEMs are not in use).
Symbol
Meaning
(s, S ) (e, E) (ske1 , K e1 ) ct k pq kee , kes , k se ck h k cS MixKey(ck, ·) MixHash(h, d) EncryptAndHash DecryptAndHash
Static keypair (X25519) Ephemeral DH keypair (X25519) Ephemeral KEM keypair (ML-KEM-768) KEM ciphertext KEM shared secret (post-quantum) DH shared secrets (classical) Chaining key (updated by MixKey) Handshake hash Symmetric cipher key (from MixKey) Encrypted static public key (AEAD) HKDF(ck, input) → (ck′ , k) h ← HASH(h∥d) AEAD encrypt, then MixHash MixHash, then AEAD decrypt
3.6
4
analysis has shown that these PQNoise patterns can achieve similar security goals as their ECDH counterparts [7]. 4.2
Hybrid Forward Secrecy Methodology Conceptually, a hybrid Noise pattern is an interleaving of a classical pattern with a PQ pattern. To support hybrid Noise patterns, two additional tokens are also defined [11]: • e1 : A secondary ephemeral key (specifically used for a KEM). This token indicates that one party generates an ephemeral KEM key pair (ML-KEM) and sends the public key as part of the handshake message. • ekem1 : An encapsulation to the secondary ephemeral key. This token indicates that the other party performs KEM encapsulation using the peer’s ephemeral KEM public key ( e1 ), sending the ciphertext.
Methodology
This section outlines the methodology underlying the postquantum and hybrid extensions of NoisePQC++. We first describe how classical Noise handshake operations are translated into KEM-based post-quantum patterns, and then show how classical ECDH and ML-KEM are combined to achieve hybrid forward secrecy. Together, these choices motivate the architecture and implementation presented in the following section.
Internally, an HFS handshake such as XXhfs will execute all the classical tokens of XX (e.g., e, ee, s, se ) and the PQ tokens ( e1, ekem1 ) in a coordinated manner. For example, in XXhfs: 1. Initiator sends classical ephemeral e and a PQ ephemeral e1 in its first message. 2. Responder, in reply, sends classical ephemeral e and static s as in XX, and encapsulates to the initiator’s PQ ephemeral ( ekem1 token), sending the ML-KEM ciphertext. Now responder derives two secrets: one from ECDH ee and one from PQ ekem1 . 3. Initiator receives the responder’s message, performs the ECDH and decapsulates the PQ ciphertext with its ephemeral KEM private key, obtaining the same two shared secrets. Then both secrets are mixed into the chaining key of the handshake (usually concatenated or XORed through the HKDF mixing process) to produce the final session keys. The effect is that the session keys are secure unless both X25519 and MLKEM are broken. We maintain the Noise pattern’s rule that all operations are folded into the key schedule in a defined order, preserving forward secrecy and authentication properties. As an example, we provide a detailed protocol transcript of XXhfs in Figure 1 (notational references to the protocol transcript are given in Table 1). All hybrid patterns in NoisePQC++ (documented fully in our Patterns module source, which is introduced in Section 5, and the documentation guide in our repository [21]) are constructed to preserve the message flow and ordering constraints of the base patterns, ensuring that no additional round
4.1
KEM-Based Methodology for PQ Noise Patterns Integrating KEMs for pure PQ patterns into the Noise framework is non-trivial and requires defining new handshake tokens analogous to e and ee . The PQNoise proposal [7] introduced two new tokens: • ekem (Encapsulate to recipient’s key): This token indicates that the sender will perform a KEM encapsulation to either the receiver’s static or ephemeral public key (depending on the pattern context), send the resulting ciphertext, and both parties will derive a shared secret from it. • skem (Static key encapsulation): This token indicates that the sender will send a KEM ciphertext that encapsulates to the receiver’s static public key. In practice, skem is used in patterns where one party’s static key needs PQ protection, analogous to how ss covers staticstatic ECDH exchanges. By substituting ECDH tokens with these KEM tokens, one can derive PQ Noise patterns. For example, the classical XX pattern involves tokens: e → e, ee, s → s, se . The corresponding pqXX pattern replaces ECDH operations with KEM operations: an initiator’s ephemeral KEM public key is sent ( e as usual), the responder encapsulates to it ( ekem in responder’s message), and static keys are sent protected by the KEM-derived secret rather than an ECDH secret. The result is that both sides arrive at a shared session key via the KEM instead of ECDH. Formal 4
Initiator (I)
Application Code import noise; using namespace Noise;
Responder (R)
Key material: Static: (sI , S I ) via X25519 Static: (sR , S R ) via X25519 State: ck, h ← Initialize(protocol_name)
Layer 4 — Facade
C++23 Modules Single namespace: Noise 11 production modules + 3 debug variants
Noise (noise.cppm)
Layer 3 — Protocol Orchestration HandshakeState WriteMessage() / ReadMessage() Token Processing
Message 1: → e, e1 Writes: e: (eI , E I ) ← DH.Gen() h ← MixHash(h, E I ) e1: (skIe1 , KIe1 ) ← KEM.Gen() h ← MixHash(h, KIe1 ) Send: E I ∥KIe1
Reads: Store E I ; h ← MixHash(h, E I )
82 Patterns 57 Classical 13 Post-Quantum 12 HFS
Layer 2 — State Management SymmetricState MixKey() / MixHash() EncryptAndHash() / Split()
Store KIe1 ; h ← MixHash(h, KIe1 )
CipherState AEAD Encrypt / Decrypt Nonce Management
Layer 1 — Cryptographic Primitives Cipher ChaCha20-Poly1305 AES-256-GCM
Message 2: ← e, ee, ekem1, s, es Reads:
Protocol Pattern + Algorithm Config
Hash SHA-256 / SHA-512 BLAKE2b / BLAKE2s
Dh (Key Exchange) X25519 / X448 (ECDH) ML-KEM-512/768/1024 (KEM)
Layer 0 — Foundation Common Types, Constants, Enums
Errors NoiseError Hierarchy
Pattern Token Definitions Message Sequences
Botan 3.10.0 Cryptographic Library (External) AEAD, Hashing, ECDH, ML-KEM
Store ER ; h ← MixHash(h, ER )
Writes: e: (eR , ER ) ← DH.Gen() h ← MixHash(h, ER )
ee: kee ← DH(eI , ER ) ck, k ← MixKey(ck, kee )
ee: kee ← DH(eR , E I ) ck, k ← MixKey(ck, kee )
ekem1: k pq ← Decaps(skIe1 , ct) ck, k ← MixKey(ck, k pq )
ekem1: (ct, k pq ) ← Encaps(KIe1 ) ck, k ← MixKey(ck, k pq )
module defines the exception hierarchy, including NoiseError , HandshakeError , and InvalidTokenError .
←
s: cS ← EncryptAndHash(S R )
5.1.2 Layer 1 Layer 1 contains the cryptographic primitive modules. Except for the KEM algorithm, all other algorithms supported in this layer are based on the Noise Protocol Framework Specifications [13].
s: SR DecryptAndHash(cS ) es: kes ← DH(eI , S R ) ck, k ← MixKey(ck, kes )
Figure 2: Shows the 5-layer module architecture of NoisePQC++.
es: kes ← DH(sR , E I ) ck, k ← MixKey(ck, kes ) Send: ER ∥ct∥cS
a) Cipher: Wraps AEAD encryption and decryption. We support ChaCha20-Poly1305 and AES-256-GCM through Botan. Nonce management is handled primarily by CipherState , and key material is wiped when no longer needed.
Message 3: → s, se Writes: s: cS ← EncryptAndHash(S I )
Reads: s: S I ← DecryptAndHash(cS )
se: k se ← DH(sI , ER ) ck, k ← MixKey(ck, k se ) Send: cS
se: k se ← DH(eR , S I ) ck, k ← MixKey(ck, k se )
b) Hash: Provides hashing, HMAC, and HKDF functionality. Supported algorithms are SHA-256, SHA-512, BLAKE2b, and BLAKE2s. The module supports both one-shot and incremental hashing for transcript maintenance and key derivation.
Split: (kI→R , kR→I ) ← HKDF(ck, ∅) ⇒ Transport encryption with derived session keys
c) Dh: Unifies classical ECDH and post-quantum KEM operations behind one interface. It supports X25519 and X448 for ECDH, and ML-KEM-512/768/1024 for KEM. The interface exposes key generation, ECDH shared-secret derivation, and KEM encapsulation/decapsulation. A KeyAlgo enum identifies the active algorithm, and higher layers use IsKEM() to select ECDH or KEM logic. Each algorithm produces its shared secret at its specified length (32 bytes for X25519 and all ML-KEM parameter sets, 56 bytes for X448); every secret is absorbed through the same HKDF-based MixKey() operation, so downstream code treats ECDH and KEM outputs uniformly.
Figure 1: Two-party protocol transcript of the XXhfs handshake (Noise_XXhfs_25519+M768_ChaChaPoly_SHA256).
trips are needed beyond what the slower primitive might require (in practice, the hybrid patterns have the same number of messages as the greater of the classical or PQ pattern). This property is hybrid forward secrecy to emphasize that forward secrecy holds even in a post-quantum context and against retroactive attacks on one of the algorithms. d) Pattern: Represents handshake patterns as token sequences grouped by message. NoisePQC++ includes standard classical 5 Architecture and Implementation Noise patterns, published PQNoise patterns, and HFS variants. The module also validates token ordering and related constraints 5.1 Layered Module Architecture NoisePQC++ is organized as layered C++ modules that before execution. mirror the structure of the Noise protocol. It separates cryptographic primitives, protocol state objects, and handshake logic. 5.1.3 Layer 2 Layer 2 manages the evolving protocol state. Figure 2 shows the overall architecture. a) CipherState: Tracks the key and nonce for one AEAD in5.1.1 Layer 0 stance. After the handshake, two CipherState objects are used for Layer 0 provides shared utilities and error handling. The transport encryption, one per direction. The module provides auCommon module defines core types, constants, algorithm iden- thenticated encryption/decryption, automatic nonce incrementtifiers, compile-time options, and logging controls. The Errors ing, optional Rekey() support, and overflow checks. 5
b) SymmetricState: Maintains the handshake’s chaining key (ck) and handshake hash (h) . It is initialized from the protocol name and provides MixKey() , MixHash() , and Split() . ECDH and KEM outputs are handled identically by mixing the resulting shared secret into ck .
Phase 1: Configuration Application Select Pattern + Algorithm
Protocol
5.1.4 Layer 3 Contains protocol and token processing logic.
Configure Cipher
Create
HandshakeState
a) Protocol: Combines a pattern with concrete algorithm choices to form a full protocol configuration. Examples include Noise_XX_25519_ChaChaPoly_SHA256 , Noise_pqXX_M768_ChaChaPoly_SHA256 , and Noise_XXhfs_25519+M768_ChaChaPoly_SHA256 . The Protocol class can be built from components or parsed from a string and enforces consistency between pattern type and selected algorithms.
Configure Hash
Cipher Selection ChaCha20 / AES-GCM
Configure DH/KEM
Hash Selection SHA-256/512, BLAKE2
DH/KEM Selection X25519/X448/ML-KEM
Initialize
Phase 2: Handshake HandshakeState
Process Tokens
WriteMessage()
Outbound Message
Token Processing
b) HandshakeState: Implements handshake execution and token processing. A HandshakeState is initialized with a Protocol , the required static keys, and the optional PSK or prologue data, then advances through the pattern using WriteMessage() and ReadMessage() . Internally, it maintains the SymmetricState , handshake cipher material, the relevant local and remote ECDH/KEM keys, and pattern progress state. During execution, e and e1 generate ephemeral public keys, s sends the local static public key, ee / es / se / ss compute and mix ECDH shared secrets, ekem / ekem1 / skem perform KEM encapsulation or decapsulation and mix the resulting shared secret, and psk mixes the pre-shared secret. Handshake payloads are then processed with EncryptAndHash() or DecryptAndHash() to preserve transcript binding and authenticated protection. This same structure supports hybrid handshakes: if a message contains both classical and PQ tokens, HandshakeState executes them in declared order and mixes each resulting secret into the chaining key in sequence. After the final handshake message, Split() derives the two transport CipherState objects and the handshake transitions to transport mode. Any attempt to continue the handshake raises HandshakeDoneError .
e: Generate s: Send ephemeral key static key
ReadMessage()
Inbound Message
ee, es, se, ss: ekem, skem, e1, ekem1: DH exchange KEM encap/decap
Dh Module Shared secret
Handshake Complete
SymmetricState
MixHash()
EncryptAndHash() DecryptAndHash()
CipherState (handshake)
Phase 3: Transport Split() Initiator -> Responder Responder -> Initiator
CipherState (send)
CipherState (receive)
EncryptWithAd()
DecryptWithAd()
Encrypted Decrypted 5.1.5 Layer 4 App Data App Data Layer 4 exposes the NoisePQC++ API to application code. Figure 3 shows the runtime flow of handshakes from application Figure 3: Runtime Handshake flow: app to transport encryption. calls to transport encryption.
5.2
Implementation and Integration This section elaborates the practical engineering contributions introduced in Section 1: cross-platform build support, instrumentation, and integration with real networking environments.
and improves portability by avoiding runtime library dependencies. Within the implementation, Botan is used through its standard APIs. For example, X25519 key generation uses Botan’s PK_Key_Agreement_Key , while ML-KEM encapsulation uses Botan’s KEM interfaces for the selected parameter set. Memory safety is supported through C++ RAII [29], secure containers where possible, memory scrubbing on destruction, and spans and smart pointers instead of raw pointers. NoisePQC++ is currently single-threaded at the HandshakeState level to reduce the complexity of protocol state management, with the potential to adopt a multithreaded architecture in future revisions.
5.2.1 Cross-Platform Build and Botan Integration Building a C++23 codebase with modules and a large cryptographic dependency across platforms is non-trivial. We use CMake (version ≥ 4.0) [23] build system with the Ninja generator [24] and require modern compilers with module support: Clang 18.1 [25], GCC 15.2 [26], or MSVC 19.44 [27]. Custom toolchain files and test scripts validate builds on Linux, macOS, and Windows. To simplify builds, we bundle the minimum required cryptographic source modules from the latest stable Botan 3 release for each supported platform and architecture, following its minimized build guide [28]. CMake selects the correct platform sources and compiles them into a standalone static library. This proved simpler for C++ module integration
5.2.2 Instrumentation and Logging A distinguishing feature of NoisePQC++ is its handshake instrumentation for debugging and analysis. In debug builds, the library can log token processing, state transitions, key-mixing events, and other internal protocol steps. Rather than scattering statements of #ifdef DEBUG throughout production code, we 6
Table 2: Feature comparison of post-quantum Noise implementations Capability / Feature
PQNoise
SecITC 2024 Proto
Clatter
NoisePQC++ (ours)
Yes (in base library)
Partial (12 core)
Partial (omits some)
Yes (full)
Partial (some tested)
Yes (12 fundamental)
Yes (all 13)
Yes (all 13)
No
Yes (12 combined)
Yes (Hybrid)
Yes (all interactive)
Possibly 512 only
512 only
Yes (512,768,1024)
Yes (512,768,1024)
DH support (25519, 448)
Yes
Yes
25519 only
Yes (25519, 448)
Static key authentication
Yes
Yes
Yes
Yes
PSK support
Yes
Not mentioned
? (not explicit)
Yes (all psk patterns)
Deferred patterns
Yes (in base Noise)
Not implemented
No [12]
Yes (all deferred)
Fallback patterns
No
No
No
No (planned)
Implementation language
Go (prototype)
C (Noise-C modified)
Rust
C++23
Logging/Instrumentation
Minimal
No
Minimal
Extensive (color logs)
Test suite
Basic sanity tests
Experiment scripts
Yes (good)
Comprehensive
Platform support
Linux/Unix (Go)
Linux (targeted)
All (Rust)
Win/Linux/macOS
All 57 classical handshake variants PQNoise patterns (13) Hybrid (classical+PQ) patterns Multi KEM (ML-KEM-512/768/1024)
maintain parallel debug variants of core state-machine modules, including HandshakeState.debug and SymmetricState.debug . A CMake option selects either the production or debug implementation at compile time. As a result, production builds incur zero logging overhead because the debug code is never compiled into release binaries. By default, debug builds enable full logging. The output is human-readable and color-coded, with categories for state transitions, token handling, and cryptographic events. To avoid accidental disclosure, logging is by default conservative: it reports metadata such as sizes, roles, and protocol events, but not secret key material. These categories are documented in the project’s Logging guide, and users can disable logging globally or selectively through API calls [21]. This instrumentation is especially valuable for experimental and research use. Users can run example handshakes, including the interactive “pattern zoo,” and observe how the transcript state evolves and how hybrid handshakes combine multiple secrets. This transforms the protocol from an opaque “black-box” process into a transparent and analyzable execution trace and, to the best of our knowledge, is not a common feature in existing Noise protocol implementations. Complete color coded demo debug logs of XX, pqXX and XXhfs are available in our repository under the output folder [21].
execution visibly includes an additional KEM ciphertext and corresponding ekem handling compared to classical XX. For validation, we integrate the official Noise test vectors for classical patterns [22]. Since there is no standardized test-vector suite for PQNoise or hybrid patterns, we generated deterministic test cases using fixed random seeds. These provide reproducible outputs and can serve as reference vectors for future implementations. NoisePQC++ provides a single public module, Noise , which exposes core abstractions such as Protocol , HandshakeState , and CipherState . These abstractions constitute the primary interface through which higher-level systems and applications can be systematically integrated with the library. Botan remains an internal dependency and does not leak into the public API, lowering the barrier to adopting a post-quantum-capable implementation. At the same time, production deployment of PQ handshakes should remain cautious. Although ML-KEM has been standardized, post-quantum algorithms are newer and less operationally mature than classical algorithms. Hence, the hybrid mode is often the most prudent default. NoisePQC++ supports this directly through hfs patterns and protocol strings such as 25519+M768 , enabling early experimentation with quantumresistant secure channels in applications such as VPNs and messaging systems.
5.2.3 Example Integration and Use Cases To demonstrate deployability, we developed several example applications around NoisePQC++. One is a simple ASIObased [30] client-server pair that performs a Noise handshake over TCP. We also provide a multi-protocol Noise server that accepts classical XX, pqXX, or hybrid XXhfs handshakes. The server identifies the handshake variant from the initial message format and instantiates the corresponding HandshakeState . Because classical, PQ, and hybrid modes share the same library interface, the surrounding application logic remains nearly identical; in most cases, only the protocol name string changes. We also include an interactive Pattern Explorer that lets users select any classical, PQ, or hybrid pattern and observe a simulated handshake through the logging system. For example, a pqXX
We evaluate NoisePQC++ along three dimensions: feature coverage, correctness, and performance. First, we compare its protocol support and flexibility with prior implementations. Second, we assess the correctness through testing and expected interoperability behavior. Third, we measure the practical overhead of classical, post-quantum, and hybrid handshakes across latency, CPU cost, message size, and network performance.
6
6.1
Evaluation
Feature Coverage and Correctness Table 2 provides a high-level comparison of NoisePQC++ with the prior implementations discussed (PQNoise, SecITC prototype, Clatter) [7–9]. As shown, NoisePQC++ offers the broadest support for patterns and algorithms. Importantly, it is the only one that we know of that covers the deferred pattern 7
variants (those with a “1” token, which are edge cases for when static keys are sent later in the handshake) and the various PSK patterns. Although these patterns are less commonly used, implementing them in the PQ and hybrid context demonstrates the generality of our approach. Clatter, for example, left deferred patterns to be “implemented by the user” if needed, whereas we included them by systematically extending the pattern generation rules. We also include both widely used curves (X25519, X448) and the full range of ML-KEM parameters, whereas others often fixed on a single parameter set for simplicity. This gives NoisePQC++ the flexibility to target different security levels (e.g., one could instantiate a Noise handshake with X448 + ML-KEM-1024 for a very high security margin, albeit with some performance cost).
keys and ciphertexts are much larger than X25519 (1184 vs. 32 bytes and 1088 vs. 32 bytes), although the HKDF-based key schedule reduces every exchange to the same 32-byte symmetric keys, so downstream symmetric encryption is unchanged. X448 increases key size only modestly (56 vs 32 bytes), making this ECDH→KEM transition the dominant source of wire overhead, as shown in Fig. 6. ML-KEM-1024 is notable in that its public key and ciphertext are both 1568 bytes.
e) Message Overhead Analysis: These size increases compound across handshake messages. PQ patterns incur 28.6– 46.8× more wire overhead than classical, with KK highest because its classical baseline is very small as detailed in Fig. 4c. HFS grows less than pure PQ in multi-message patterns (e.g., XX: HFS 14.4× vs. PQ 36.1×) because it retains compact classical ECDH tokens while adding a KEM operation instead of 6.2 Correctness and Interoperability Our test suite (we use Catch2 [31], a popular C++ testing replacing all ECDH operations. NNhfs is the exception at 33.0× framework) confirms that for every pattern variant, the initiator because classical NN starts from only 80 bytes. and responder derive identical session keys and that security f) Network Round-Trip Time: TCP loopback measurements properties hold (e.g., if a wrong pre-shared key is used, the confirm the local benchmark results under transport overhead. handshake fails with an error, as expected). We have not yet con- pqNN achieves the lowest mean RTT at 425.0 µs, outperforming ducted formal interoperability testing with other libraries. How- classical NN at 516.2 µs despite larger payloads, indicating that ever, by adhering closely to the specifications and using standard- computation rather than payload size dominates in loopback ized algorithms, we expect that an initiator using NoisePQC++ as detailed in Fig. 4d. Variance is higher than in local benchand a responder using another library with the same pattern and marks because of OS scheduling, TCP stack latency, and context algorithms will interoperate. This is an area for future empirical switching, but P99 latency remains below 2 ms in all modes. testing. XXhfs is the slowest, with 1186 µs mean RTT, due to three protocol messages and dual ECDH+KEM operations.
6.3
Performance and Benchmarks We evaluate NoisePQC++ across seven performance metrics using Google Benchmark [32] and ASIO networking library [30] on an Intel i7 (2.30 GHz, 32 GB RAM) MacBook Pro under Clang 18 compiler with Release optimizations. The results we present next are an average over several runs of the benchmarking scripts. a) Handshake Latency Comparison: ML-KEM-768 handshakes are consistently faster than X25519, with overhead ratios of 0.66–0.85× as shown in Fig. 4a. This likely reflects efficient lattice arithmetic and Botan’s optimized x86-64 implementation. Among all the interactive patterns, the NN pattern is the fastest in all three modes, while IK and KK are slower due to additional static-key operations. HFS increases cost to 1.25–1.70× over classical because each handshake performs both ECDH and KEM, trading moderate overhead for defense-in-depth. b) CPU Time Analysis: CPU time closely matches wall-clock time across all modes, with CPU/real ratios above 0.98, indicating computation-bound behavior (Fig. 5). Classical patterns show the widest spread because of the X448 versus X25519 gap, whereas PQ patterns cluster more tightly across ML-KEM levels. HFS timings are roughly additive, reflecting the combined cost of ECDH and KEM within a single handshake. c) Key Generation Performance: Key generation helps explain the latency results as shown in Fig. 4b. ML-KEM-768 takes 59.1 µs, nearly identical to X25519 at 57.2 µs, while ML-KEM512 is the fastest primitive at 34.9 µs. Even ML-KEM-1024 remains below 100 µs at 93.3 µs, scaling roughly with security level (512 → 768 → 1024 ≈ 1.0× → 1.7× → 2.7×). In contrast, X448 is 4.0× slower than X25519 (227.9 µs vs. 57.2 µs), showing that PQ handshakes benefit from both efficient encapsulation and competitive key generation. d) Key and Ciphertext Sizes: The main cost of post-quantum migration is bandwidth, not computation. ML-KEM-768 public
g) Throughput Scaling: For this benchmark, we only selected the XX pattern to compare the three modes of classical, PQ only, and hybrid. Under concurrent load, pqXX scales best, reaching 1313.9 hs/s at 10 clients versus 918.3 hs/s for XX and 793.8 hs/s for XXhfs as shown in Fig. 7. This advantage follows from its lower per-handshake CPU cost, which allows more handshakes to complete under contention. XXhfs also shows the highest tail latency under load (P99: 11.1 ms at 10 clients vs. 9.9 ms for XX), reflecting the cost of combined ECDH+KEM operations. All modes improve up to 5 clients, but XX and XXhfs show diminishing gains from 5 to 10 clients, suggesting near-saturation on the 8-core CPU, whereas pqXX still has headroom. 6.4
Summary of Our Findings
Overall, the evaluation shows that NoisePQC++ meets its main goals across coverage, correctness, and performance. It provides broader protocol support than prior implementations, supports practical confidence through testing and instrumentation, and shows that post-quantum and hybrid Noise handshakes remain feasible with manageable overhead. This overhead is modest in practice. The largest ephemeral structure is an MLKEM key pair (∼2.3 KB for ML-KEM-1024 keys, plus minor overhead), and total handshake state remains only a few kilobytes. C++ RAII ensures prompt release of temporary resources. For side-channel resistance, we rely on Botan’s constant-time implementations and clear sensitive material where appropriate. We do not currently implement SEEC from PQNoise [7], instead relying on Botan’s cryptographic PRNG for secure key generation. These results suggest that NoisePQC++ is not only a research prototype, but also a practical basis for experimentation and evaluation toward future deployment of quantum-resistant secure channels. 8
Handshake Latency: Classical vs Post-Quantum vs Hybrid Classical (X25519) PQ (ML-KEM-768) HFS (X25519+ML-KEM-768)
1425
Latency (microseconds)
1200
227897
1416
1137
1127
1000 898
800
764
750
741
688
600 404
400
Key Generation Performance
200000
1173
Key Generation Time (ns)
1400
150000 100000
93276 59051
57242
50000
34876
314
0
200
519
8
NN
XX
IK
Handshake Pattern
ML-
4
102
KEM
(b) Key generation performance Network Handshake Round-Trip Time Classical PQ HFS
6928
1200
Classical Post-Quantum Hybrid (HFS)
1186
5696
1000
5000 4496
Mean RTT (us)
Total Bytes Exchanged
-76 KEM ML-
Algorithm
Handshake Message Overhead: Bytes per Handshake 6000
8
-51 KEM ML-
KK
(a) Handshake latency comparison 7000
2
X44
X25
0
4000 3000
2760
2636
2722
960
600
516
2668
425
400
2288
908
825
800
2000 200 1000
(c) Message overhead per handshake
HF S
XX
XX
XX
PQ
PQ
KK
NN
0
96
IK
Handshake Pattern
NN
XX
HF S
144
NN
NN
192
80
0
Handshake Mode
(d) Network round-trip time
Figure 4: Benchmark results in classical (X25519), PQ (ML-KEM-768), and HFS (X25519+ML-KEM-768) modes. Classical Handshakes
2092
779
Hybrid (HFS) Handshakes 2239
773
2000
1300
500 400 331
300
1500
200
1200
500
100
hfs
fs
KK
IKh
hfs XX
Pattern
NN
pq
hfs
KK
IK
XX
pq
pq
pq
KK
IK
XX
Pattern
0
NN
0
NN
0
Pattern
Figure 5: CPU time across classical, PQ, and hybrid patterns. Public Key Sizes
1600
800
Algorithm
10
24 M-
making it useful both as a library and as a platform for studying post-quantum Noise handshake behavior. Our evaluation indicates that this broader support does not impose prohibitive cost. Post-quantum and hybrid Noise handshakes remain practical, with manageable latency and computational overhead, while hybrid modes provide a prudent migration path by combining classical and post-quantum assumptions within a single handshake. As NIST-standardized PQC moves toward deployment, NoisePQC++ provides a concrete step toward quantum-resistant secure channels built on the Noise framework. Future research will concentrate on five primary directions: (i) extending the experimental evaluation through finer-grained and cross-platform benchmarking; (ii) integrating NoisePQC++ into practical applications, including prototype implementations for virtual private networks (VPNs) and secure messaging systems [33]; (iii) implementing fallback and negotiation mechanisms to enhance interoperability across heterogeneous deployment environments; (iv) investigating post-quantum digital signature schemes for authentication; and (v) incorporating
Figure 6: Public key and ciphertext sizes for DH and ML-KEM.
7
8
10
8 76 MML -KE
19 55 X2
24 M-
10
8 ML -KE
ML -KE
M-
76
2 51 MML -KE
48 X4
19 55 X2
Algorithm
6
Number of Concurrent Clients
56
32
0
2
56
32
0
4
Figure 7: Throughput Scaling with Concurrent Clients. 51
200
M-
400
200
48
400
800
2
768
600
ML -KE
600
1088
1000
X4
Size (bytes)
800
800
900
600
1200
ML -KE
1184
1000
1000
1568
1400
1200
1100
700
Ciphertext / DH Exchange Sizes
1600
1568
1400
PQXX XX XXHFS
990
1000
Handshakes per Second
920
CPU Time (us)
1500
500
Size (bytes)
Throughput Scaling with Concurrent Clients
2243
1828
600
CPU Time (us)
CPU Time (us)
788
700
2000
1000
Post-Quantum Handshakes
800
2750
2707
2500
Conclusion and Future Work
Building on the PQNoise designs and the hybrid-forwardsecrecy extension, NoisePQC++ demonstrates that the Noise Protocol Framework can be extended to support post-quantum and hybrid key exchange while preserving the simplicity and flexibility that makes Noise attractive. By unifying classical, post-quantum, and hybrid handshakes in a single architecture, our work helps bridge the gap between proposed PQ and hybrid Noise designs and a usable software framework. Compared with prior implementations, NoisePQC++ provides broader pattern coverage, support for multiple ML-KEM parameter sets, and a unified architecture spanning classical ECDH, PQ KEM, and hybrid combinations. The implementation also includes practical tooling for integration, debugging, and experimentation, 9
HQC, the code-based KEM selected by NIST in March 2025 to [13] T. Perrin, “The Noise Protocol Framework.” https://no iseprotocol.org/noise.html. complement ML-KEM [37], and benchmarking it against the ML-KEM parameter sets evaluated here once its standard (HQC- [14] A. Sarkar, D. Guha Roy, and P. Datta, “An overview of KEM) is finalized. Collectively, these efforts aim to advance the discrete logarithm problem in cryptography,” in ProNoisePQC++ toward a fully post-quantum secure channel deceedings of Third International Conference on Advanced sign that achieves comprehensive coverage of the Noise protocol Computing and Applications (D. Giri, S. Das, J. M. Corspecification [13]. chado Rodríguez, and D. De, eds.), (Singapore), pp. 129– 143, Springer Nature Singapore, 2024. Code Availability [15] D. Stebila, S. Fluhrer, and S. Gueron, “Hybrid key exThe NoisePQC++ implementation is publicly available as change in TLS 1.3,” Internet-Draft draft-ietf-tls-hybridan open-source repository on GitHub [21]. Reproducibility design-11, Internet Engineering Task Force, 2024. https: instructions, Docker image tags, and immutable SHA-256 image //ietf.org. digests are provided in the repository’s documentation. The [16] C. J. Tjhai, M. Tomlinson, G. Bartlett, S. Fluhrer, D. V. exact version evaluated in this work is archived on Zenodo for Geest, O. Garcia-Morchon, and V. Smyslov, “Multiple key long-term access and reproducible citation [34]. exchanges in the internet key exchange protocol version 2 (ikev2),” RFC 9370, Internet Engineering Task Force, May Acknowledgment 2023. https://rfc-editor.org. This paper is based upon work supported by the National [17] “Yawning Angel / nyquist · GitLab.” https://gitlab.c Science Foundation under award No. 2347249 and US Army om/yawning/nyquist, Apr. 2026. under grant No. W911NF2120076. [18] A. Hülsing, K.-C. Ning, P. Schwabe, F. J. Weber, and P. R. Zimmermann, “Post-quantum wireguard,” in 2021 IEEE References Symposium on Security and Privacy (SP), pp. 304–321, [1] “Noise Protocol Framework.” https://noiseprotoco IEEE, 2021. l.org/. [2] N. Kobeissi, G. Nicolas, and K. Bhargavan, “Noise ex- [19] “Botan — Botan.” https://botan.randombit.net/. plorer: Fully automated modeling and verification for arbi- [20] N. Ahmed, L. Zhang, and A. Gangopadhyay, “A survey of post-quantum cryptography support in cryptographic trary noise protocols,” in 2019 IEEE European Symposium libraries,” in 2025 IEEE International Conference on Quanon Security and Privacy (EuroS&P), pp. 356–370, IEEE, tum Computing and Engineering (QCE), vol. 01, pp. 906– 2019. 917, 2025. [3] T. Perrin and M. Marlinspike, “The double ratchet algoN. Ahmed, “NoisePQC++: A C++23 implementation of [21] rithm.” https://signal.org/docs/specifications the Noise Protocol Framework with Post-Quantum Cryp/doubleratchet/doubleratchet.pdf, 2016. tography.” https://github.com/nata11/NoisePQC [4] I. T. L. Computer Security Division, “Post-Quantum Cryppp, 2026. tography | CSRC | CSRC.” https://csrc.nist.gov/ [22] noiseprotocol, “Test vectors.” https://github.com/n projects/post-quantum-cryptography, Jan. 2017. oiseprotocol/noise_wiki/wiki/Test-vectors. [5] L. Zhang, A. Miranskyy, and W. Rjaibi, “Quantum advantage and the Y2K bug: A comparison,” IEEE Software, [23] “CMake - Upgrade Your Software Build System.” https: //cmake.org/. vol. 38, no. 2, pp. 80–87, 2020. “Ninja, a small build system with a focus on speed.” http [24] [6] L. Zhang, A. Miranskyy, W. Rjaibi, G. Stager, M. Gray, and s://ninja-build.org/. J. Peck, “Making existing software quantum safe: A case [25] “Clang 18.1.6 Release Notes — Clang 18.1.6 documentastudy on IBM Db2,” Information and Software Technology, tion.” https://releases.llvm.org/18.1.6/tools vol. 161, p. 107249, 2023. /clang/docs/ReleaseNotes.html. [7] Y. Angel, B. Dowling, A. Hülsing, P. Schwabe, and F. Weber, “Post quantum noise,” in Proceedings of the 2022 [26] “GCC 15 Release Series - GNU Project.” https://gcc. gnu.org/gcc-15/. ACM SIGSAC Conference on Computer and CommunicaTylerMSFT, “C and C++ in Visual Studio.” https://le [27] tions Security, pp. 97–109, 2022. arn.microsoft.com/en-us/cpp/overview/visua [8] J. Renckens, P. B. Rønne, J. Großschädl, and P. Y. Ryan, l-cpp-in-visual-studio?view=msvc-170. “An evaluation of post-quantum and hybrid noise protocol [28] “Building The Library — Botan.” https://botan.rand variants on mobile devices,” in International Conference ombit.net/handbook/building.html#minimized on Information Technology and Communications Security, -builds. pp. 149–169, Springer, 2024. [29] “RAII - cppreference.com.” https://en.cppreferenc [9] J. Lepistö, “Jmlepisto/clatter.” https://github.com/j e.com/cpp/language/raii. mlepisto/clatter, Mar. 2026. “Asio C++ Library.” https://think-async.com/Asi [30] [10] “Katzenpost/nyquist.” Katzenpost, Mar. 2025. https: o/. //github.com/katzenpost/nyquist. [31] “Catchorg/Catch2.” Catch Org, Apr. 2026. https://gi [11] T. Perrin, “KEM-based Hybrid Forward Secrecy for Noise.” thub.com/catchorg/Catch2. https://github.com/noiseprotocol/noise_hfs [32] “Google/benchmark.” Google, Apr. 2026. https://gith _spec, Mar. 2026. ub.com/google/benchmark. [12] National Institute of Standards and Technology (US), [33] L. Zhang, “Toward quantum-safe software engineering: A “Module-lattice-based key-encapsulation mechanism stanvision for post-quantum cryptography migration,” arXiv dard,” Tech. Rep. NIST FIPS 203, National Institute of preprint arXiv:2602.05759, 2026. Standards and Technology (U.S.), Washington, D.C., Aug. [34] N. Ahmed, “NoisePQC++: A C++23 implementation of 2024. https://nvlpubs.nist.gov/nistpubs/FIPS the noise protocol framework with post-quantum cryptog/NIST.FIPS.203.pdf. 10
raphy.” Zenodo, Apr. 2026. https://doi.org/10.528 1/zenodo.19782168. [35] National Institute of Standards and Technology, “ModuleLattice-Based Key-Encapsulation Mechanism Standard,” NIST FIPS 203, U.S. Department of Commerce, Gaithersburg, MD, Aug. 2024, doi: 10.6028/NIST.FIPS.203. [36] National Institute of Standards and Technology, “Recommendations for Key-Encapsulation Mechanisms,” NIST Special Publication 800-227, U.S. Department of Commerce, Gaithersburg, MD, Sept. 2025, doi: 10.6028/NIST.SP.800-227. [37] G. Alagic et al., “Status Report on the Fourth Round of the NIST Post-Quantum Cryptography Standardization Process,” NIST Internal Report 8545, U.S. Department of Commerce, Gaithersburg, MD, Mar. 2025, doi: 10.6028/NIST.IR.8545.
11