Pith. sign in

REVIEW 3 major objections 5 minor 38 references

NoisePQC++: A Unified NIST-Compliant PQC and Hybrid-PQC Implementation of the Noise Protocol

T0 review · 3 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Single handshake engine runs all Noise patterns with ML-KEM

desk verdict Solid engineering paper with a real artifact; the main weakness is that PQ/hybrid conformance rests on self-generated vectors, which should be fixed before deployment claims. read the letter →

arxiv 2608.00954 v1 pith:FKFODXE6 submitted 2026-08-02 cs.CR cs.NIquant-ph

Nadeem Ahmed , Aryya Gangopadhyay , Lei Zhang This is my paper · ORCID
classification cs.CRcs.NIquant-ph
keywords post-quantumcryptographyNoiseProtocolFrameworkML-KEMhybridkeyexchangeforwardsecrecyhandshakepatternsC++23implementationencapsulationmechanism
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper presents NoisePQC++, a C++23 implementation that runs classical, post-quantum, and hybrid Noise handshakes in one architecture. It claims that all 57 classical patterns, all 13 published PQNoise patterns, and systematic hybrid ECDH+ML-KEM variants are supported, with ML-KEM-768 handshakes often faster than X25519 and hybrid overhead roughly 1.25 to 1.70 times classical latency. The goal is to show that NIST-standardized post-quantum key exchange can be dropped into the Noise protocol without forking the handshake logic, so applications can move to PQC by changing a protocol string. A sympathetic reader would care because WireGuard, WhatsApp, and other Noise-based systems need a practical migration path before quantum computers threaten their ECDH keys.

What carries the argument

The load-bearing object is a pattern-driven handshake engine where ECDH and ML-KEM live behind one generic Dh interface. The token set is extended with ekem and skem for pure PQ patterns and with e1 and ekem1 for hybrid patterns, and every ECDH or KEM shared secret is mixed into the same HKDF chaining key in token order, so the final session key depends on all secrets without any new key-combination function.

What would settle it

Run this library against an independent implementation of Noise_XXhfs_25519+M768_ChaChaPoly_SHA256 and compare the derived transport keys. If either side fails to complete or the keys differ, the full-coverage and interoperability claims are false. The paper explicitly states that no such cross-library test has been performed.

Watch

Extended reading notes

Core claim

The central claim is that a single Noise handshake state machine can treat ECDH and KEM as interchangeable exchange primitives and cover the full pattern space. The implementation extends the token set with ekem and skem, and with the hybrid tokens e1 and ekem1, and it lets every shared secret be folded into the chaining key through the standard MixKey HKDF operation. The paper reports that ML-KEM-768 handshakes run at 0.66 to 0.85 times the latency of X25519 handshakes, hybrid HFS handshakes cost 1.25 to 1.70 times classical, and pure PQ patterns enlarge wire messages by 28.6 to 46.8 times. It also claims to be the only implementation it knows of that covers deferred and pre-shared-key patt

Load-bearing premise

The claim that all PQ and hybrid pattern instantiations are correct rests on the assumption that this implementation's reading of the published PQNoise and hybrid-forward-secrecy specifications matches what independent implementations would do, since no cross-library interoperability test or published PQ test vector has yet been used to confirm it.

Editorial extensions

If this is right

  • Applications can add post-quantum or hybrid security by changing the protocol name string; the surrounding API and handshake logic stay the same.
  • Computation is not the obstacle: ML-KEM-768-only handshakes are faster than X25519-only ones, and hybrid handshakes remain within about 1.7 times classical latency.
  • Bandwidth becomes the dominant cost, with pure PQ messages 28.6 to 46.8 times larger than classical ones.
  • Full coverage now includes deferred and pre-shared-key patterns and all three ML-KEM parameter sets, giving instantiation flexibility for different security margins.
  • A single codebase can serve as a research platform for comparing classical, PQ, and hybrid Noise behavior.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The same unified exchange interface would likely make a future standardized KEM such as HQC a drop-in addition; the paper lists this as future work rather than demonstrating it.
  • Because ML-KEM can beat X25519 on latency, pure PQ mode may eventually become the performance-friendly default once operational confidence grows; the paper recommends hybrid as the prudent current choice.
  • Without cross-library interoperability testing, the 13-pattern PQ and hybrid coverage is only proven by self-consistency; a natural next step would be publishing fixed-seed test vectors so independent implementations can compare.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper presents NoisePQC++, a C++23 implementation of the Noise Protocol Framework that unifies classical, post-quantum, and hybrid handshakes. The authors claim support for all 57 classical Noise pattern variants, all 13 published PQNoise patterns, and systematic hybrid ECDH+ML-KEM (HFS) variants, using Botan as the cryptographic backend. Correctness of classical patterns is checked against official Noise test vectors; PQ and hybrid patterns are checked with deterministic, self-generated vectors. Benchmarks on a laptop-class machine report that ML-KEM-768 handshakes are often faster than X25519 and that hybrid handshakes cost roughly 1.25–1.70× classical latency. The stated goal is to provide a practical, unified, deployment-oriented reference implementation for post-quantum and hybrid Noise handshakes.

Significance. If the PQ and HFS constructions faithfully match the published PQNoise and HFS specifications, this is a significant systems contribution: a single codebase covering the full classical pattern space, multiple ML-KEM parameter sets, hybrid patterns, deferred/PSK variants, and cross-platform builds, with reproducible code and benchmarks. The use of official classical Noise test vectors, the extensive internal test suite, and the availability of instrumented debug builds are genuine strengths. However, the central coverage claim rests on conformance to external specifications that is currently supported only by self-consistency tests and self-generated vectors. The paper explicitly acknowledges the absence of formal interoperability testing. Because the contribution is breadth of pattern support, this gap is load-bearing and needs to be addressed or the claims substantially qualified.

major comments (3)
  1. [§6.2, §5.2.3] Correctness of the PQ and HFS patterns is validated only by internal self-consistency: initiator and responder agree, and deterministic vectors are generated by the same implementation. Section 5.2.3 states there is no standardized test-vector suite for PQNoise/hybrid patterns and that deterministic tests were generated with fixed seeds; Section 6.2 states 'We have not yet conducted formal interoperability testing with other libraries.' This cannot detect a systematic deviation from the PQNoise/HFS specifications, such as incorrect KEM ciphertext encoding, wrong e1/ekem1 placement, or a different MixKey ordering. Since the paper's main claim is complete support for all 13 PQ and all hybrid patterns, please add interoperability tests against an independent implementation (e.g., nyquist/PQNoise or Clatter), or at minimum have an independent party generate cross-validated reference vectors,
  2. [Abstract/§1, Fig. 2, Table 2] The pattern coverage count is internally inconsistent. The abstract and contribution list say '13 post-quantum Noise handshakes, and their hybrid variants,' but Figure 2 shows '12 HFS' (57+13+12=82 patterns), and Table 2 states hybrid support is 'all interactive' rather than all 13. The text provides only one concrete HFS transcript (XXhfs). Please provide a complete enumeration of the PQ and HFS patterns with their token sequences and protocol-name strings, and reconcile whether all 13 PQ patterns have HFS variants or only 12. This is load-bearing for the central coverage claim.
  3. [§4.2, §5.1.2(d)] The HFS construction is not specified precisely enough for independent verification. The paper informally defines e1 and ekem1 and gives one example transcript, but it does not state which base patterns receive HFS variants, the exact protocol-name grammar (e.g., '25519+M768'), or the precise MixKey ordering when ECDH and KEM secrets appear in the same message. Section 3.4 says the order follows pattern token order, but the actual token sequences are not included. Since the implementation itself is the only reference for these choices, please add a full pattern table, or cite an exact revision/commit of the HFS spec and include the generated deterministic vectors as an appendix or linked artifact.
minor comments (5)
  1. [§3.2] Typo: 'A VX2' should be 'AVX2'.
  2. [Table 2] The Clatter row for deferred patterns cites reference [12] (NIST FIPS 203), which is unrelated; either remove the citation or replace it with the appropriate source.
  3. [§6.3, Fig. 5] The CPU-time figure does not label which DH/KEM algorithms are used for the 'Classical' bars. The text says the classical spread is due to X448 vs X25519, but the reader cannot tell which primitive each bar represents. Also, the HFS CPU values for XX, IK, and KK are lower than the corresponding classical values (e.g., XXhfs 1828 µs vs XX 2092 µs), which seems inconsistent with the 'roughly additive' claim unless different primitives were used. Please clarify the exact algorithm sets and benchmark methodology.
  4. [§4.2] The phrase 'usually concatenated or XORed through the HKDF mixing process' is imprecise: MixKey uses HKDF on the chaining key and the input secret; it does not concatenate or XOR the secrets directly. Please state the exact HFS key schedule used.
  5. [§6.2] The sentence 'security properties hold' is overbroad. The tests cover derived-key agreement and some negative cases, but not a full security analysis. Suggest rephrasing to 'the tested security properties hold for the implemented test cases.'

Circularity Check

0 steps flagged · score 2.0 of 10

No circular derivation; central claims are implementation coverage and benchmarks, not fitted predictions. One minor non-load-bearing self-citation; PQ/hybrid conformance awaits independent interop testing.

full rationale

NoisePQC++ is an engineering paper: there is no equation-to-equation derivation, fitted parameter, or uniqueness theorem whose conclusion is encoded in its premise. The central claims (support for 57 classical, 13 PQNoise, and hybrid HFS patterns; ML-KEM latency; overhead ratios) are either feature-coverage statements backed by code and Table 2, or empirical measurements on a third-party crypto backend (Botan). The one self-citation, [20] used to justify Botan as the crypto provider (Section 3.2), is not load-bearing: Botan's PQC support is externally documented and the benchmarks are independent of that survey. The PQ and HFS correctness argument does rest on self-generated deterministic test vectors and initiator/responder self-consistency (Sections 3.5 and 5.2.3), and Section 6.2 explicitly concedes "We have not yet conducted formal interoperability testing with other libraries." This is a real external-validation gap for the claim of faithful PQ/HFS pattern conformance, but it is not circularity: the patterns are taken from external published specifications [7][11], and no target quantity is defined in terms of the implementation's own outputs. Under the provided scale, the only mild issue is a non-load-bearing self-citation, so a score of 2 is appropriate; the interop gap belongs in correctness risk, not circularity.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

No numeric free parameters are fitted in this engineering paper. The central claims rest on standard domain assumptions: NIST-validated ML-KEM, prior PQNoise and HFS constructions, secure HKDF mixing, and the correctness of the underlying crypto library. No new cryptographic entities are invented.

assumptions (4)
  • domain assumption ML-KEM security as specified in NIST FIPS 203
    The paper's quantum-resistance claims inherit NIST's analysis of ML-KEM; no new security proof is given (Section 2.2).
  • domain assumption PQNoise and HFS token semantics as published are correct and faithfully implemented
    The coverage and security claims depend on external specifications from prior work, but there is no interoperability testing against an independent implementation (Sections 4.1, 4.2, 6.2).
  • domain assumption Sequential HKDF MixKey of ECDH and KEM shared secrets is a sound hybrid key combination
    The paper relies on Noise's existing HKDF chaining to combine classical and post-quantum secrets, citing hybrid design recommendations rather than proving a new combination theorem (Section 3.4).
  • domain assumption Botan implements the underlying cryptographic primitives correctly and in constant time where required
    All low-level crypto, including X25519 and ML-KEM, is delegated to Botan; side-channel resistance is inherited from that library rather than independently established (Sections 3.2, 6.4).

how reviews work

0 comments
Cite this review

Pith. "Pith review of NoisePQC++: A Unified NIST-Compliant PQC and Hybrid-PQC Implementation of the Noise Protocol." pith.science (2026). https://pith.science/paper/FKFODXE6

@misc{pith2026260800954,
  author       = {Pith},
  title        = {Pith review of: NoisePQC++: A Unified NIST-Compliant PQC and Hybrid-PQC Implementation of the Noise Protocol},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/FKFODXE6}},
  note         = {Machine review of arXiv:2608.00954}
}
read the original abstract

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.

Figures

Figures reproduced from arXiv: 2608.00954 by the authors.

Figure 2
Figure 2. Shows the 5-layer module architecture of [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 1
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 mes￾sages 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… view at source ↗
Figure 3
Figure 3. Runtime Handshake flow: app to transport encryption. [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Benchmark results in classical (X25519), PQ (ML-KEM-768), and HFS (X25519 [PITH_FULL_IMAGE:figures/full_fig_p009_4.png]
Figure 5
Figure 5. Figure 5: CPU time across classical, PQ, and hybrid patterns. [PITH_FULL_IMAGE:figures/full_fig_p009_5.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

38 extracted references · 36 canonical work pages

  1. [1]

    Noise Protocol Framework

    “Noise Protocol Framework.” https://noiseprotoco l.org/

    work page

  2. [2]

    Noise ex- plorer: Fully automated modeling and verification for arbi- trary noise protocols,

    N. Kobeissi, G. Nicolas, and K. Bhargavan, “Noise ex- plorer: Fully automated modeling and verification for arbi- trary noise protocols,” in2019 IEEE European Symposium on Security and Privacy (EuroS&P), pp. 356–370, IEEE, 2019

    work page 2019

  3. [3]

    The double ratchet algo- rithm

    T. Perrin and M. Marlinspike, “The double ratchet algo- rithm.” https://signal.org/docs/specifications /doubleratchet/doubleratchet.pdf, 2016

    work page 2016

  4. [4]

    Post-Quantum Cryp- tography|CSRC|CSRC

    I. T. L. Computer Security Division, “Post-Quantum Cryp- tography|CSRC|CSRC.” https://csrc.nist.gov/ projects/post-quantum-cryptography, Jan. 2017

    work page 2017

  5. [5]

    Quantum advan- tage and the Y2K bug: A comparison,

    L. Zhang, A. Miranskyy, and W. Rjaibi, “Quantum advan- tage and the Y2K bug: A comparison,”IEEE Software, vol. 38, no. 2, pp. 80–87, 2020

    work page 2020

  6. [6]

    Making existing software quantum safe: A case study on IBM Db2,

    L. Zhang, A. Miranskyy, W. Rjaibi, G. Stager, M. Gray, and J. Peck, “Making existing software quantum safe: A case study on IBM Db2,”Information and Software Technology, vol. 161, p. 107249, 2023

    work page 2023

  7. [7]

    Post quantum noise,

    Y . Angel, B. Dowling, A. Hülsing, P. Schwabe, and F. We- ber, “Post quantum noise,” inProceedings of the 2022 ACM SIGSAC Conference on Computer and Communica- tions Security, pp. 97–109, 2022

    work page 2022

  8. [8]

    An evaluation of post-quantum and hybrid noise protocol variants on mobile devices,

    J. Renckens, P. B. Rønne, J. Großschädl, and P. Y . Ryan, “An evaluation of post-quantum and hybrid noise protocol variants on mobile devices,” inInternational Conference on Information Technology and Communications Security, pp. 149–169, Springer, 2024

    work page 2024

Show all 38 references
  1. [9]

    Jmlepisto/clatter

    J. Lepistö, “Jmlepisto/clatter.” https://github.com/j mlepisto/clatter, Mar. 2026

    2026

  2. [10]

    Katzenpost/nyquist

    “Katzenpost/nyquist.” Katzenpost, Mar. 2025. https: //github.com/katzenpost/nyquist

    2025

  3. [11]

    KEM-based Hybrid Forward Secrecy for Noise

    T. Perrin, “KEM-based Hybrid Forward Secrecy for Noise.” https://github.com/noiseprotocol/noise_hfs _spec, Mar. 2026

    2026

  4. [12]

    Module-lattice-based key-encapsulation mechanism stan- dard,

    National Institute of Standards and Technology (US), “Module-lattice-based key-encapsulation mechanism stan- dard,” Tech. Rep. NIST FIPS 203, National Institute of Standards and Technology (U.S.), Washington, D.C., Aug

  5. [13]

    The Noise Protocol Framework

    T. Perrin, “The Noise Protocol Framework.”https://no iseprotocol.org/noise.html

  6. [14]

    An overview of the discrete logarithm problem in cryptography,

    A. Sarkar, D. Guha Roy, and P. Datta, “An overview of the discrete logarithm problem in cryptography,” inPro- ceedings of Third International Conference on Advanced Computing and Applications(D. Giri, S. Das, J. M. Cor- chado Rodríguez, and D. De, eds.), (Singapore), pp. 129– ...

    2024

  7. [15]

    Hybrid key ex- change in TLS 1.3,

    D. Stebila, S. Fluhrer, and S. Gueron, “Hybrid key ex- change in TLS 1.3,” Internet-Draft draft-ietf-tls-hybrid- design-11, Internet Engineering Task Force, 2024. https: //ietf.org

    2024

  8. [16]

    Multiple key exchanges in the internet key exchange protocol version 2 (ikev2),

    C. J. Tjhai, M. Tomlinson, G. Bartlett, S. Fluhrer, D. V . Geest, O. Garcia-Morchon, and V . Smyslov, “Multiple key exchanges in the internet key exchange protocol version 2 (ikev2),” RFC 9370, Internet Engineering Task Force, May 2023.https://rfc-editor.org

    2023

  9. [17]

    Yawning Angel/nyquist · GitLab

    “Yawning Angel/nyquist · GitLab.” https://gitlab.c om/yawning/nyquist, Apr. 2026

    2026

  10. [18]

    Post-quantum wireguard,

    A. Hülsing, K.-C. Ning, P. Schwabe, F. J. Weber, and P. R. Zimmermann, “Post-quantum wireguard,” in2021 IEEE Symposium on Security and Privacy (SP), pp. 304–321, IEEE, 2021

    2021

  11. [19]

    Botan — Botan

    “Botan — Botan.”https://botan.randombit.net/

  12. [20]

    A survey of post-quantum cryptography support in cryptographic libraries,

    N. Ahmed, L. Zhang, and A. Gangopadhyay, “A survey of post-quantum cryptography support in cryptographic libraries,” in2025 IEEE International Conference on Quan- tum Computing and Engineering (QCE), vol. 01, pp. 906– 917, 2025

    2025

  13. [21]

    NoisePQC++: A C++23 implementation of the Noise Protocol Framework with Post-Quantum Cryp- tography

    N. Ahmed, “NoisePQC++: A C++23 implementation of the Noise Protocol Framework with Post-Quantum Cryp- tography.” https://github.com/nata11/NoisePQC pp, 2026

    2026

  14. [22]

    Test vectors

    noiseprotocol, “Test vectors.” https://github.com/n oiseprotocol/noise_wiki/wiki/Test-vectors

  15. [23]

    CMake - Upgrade Your Software Build System

    “CMake - Upgrade Your Software Build System.”https: //cmake.org/

  16. [24]

    Ninja, a small build system with a focus on speed

    “Ninja, a small build system with a focus on speed.” http s://ninja-build.org/

  17. [25]

    Clang 18.1.6 Release Notes — Clang 18.1.6 documenta- tion

    “Clang 18.1.6 Release Notes — Clang 18.1.6 documenta- tion.” https://releases.llvm.org/18.1.6/tools /clang/docs/ReleaseNotes.html

  18. [26]

    GCC 15 Release Series - GNU Project

    “GCC 15 Release Series - GNU Project.” https://gcc. gnu.org/gcc-15/

  19. [27]

    C and C++in Visual Studio

    TylerMSFT, “C and C++in Visual Studio.” https://le arn.microsoft.com/en-us/cpp/overview/visua l-cpp-in-visual-studio?view=msvc-170

  20. [28]

    Building The Library — Botan

    “Building The Library — Botan.” https://botan.rand ombit.net/handbook/building.html#minimized -builds

  21. [29]

    RAII - cppreference.com

    “RAII - cppreference.com.” https://en.cppreferenc e.com/cpp/language/raii

  22. [30]

    Asio C++Library

    “Asio C++Library.” https://think-async.com/Asi o/

  23. [31]

    Catchorg/Catch2

    “Catchorg/Catch2.” Catch Org, Apr. 2026. https://gi thub.com/catchorg/Catch2

    2026

  24. [32]

    Google/benchmark

    “Google/benchmark.” Google, Apr. 2026. https://gith ub.com/google/benchmark

    2026

  25. [33]

    Toward quantum-safe software engineering: A vision for post-quantum cryptography migration,

    L. Zhang, “Toward quantum-safe software engineering: A vision for post-quantum cryptography migration,”arXiv preprint arXiv:2602.05759, 2026

    2026 arXiv

  26. [34]

    NoisePQC++: A C++23 implementation of the noise protocol framework with post-quantum cryptog- 10 raphy

    N. Ahmed, “NoisePQC++: A C++23 implementation of the noise protocol framework with post-quantum cryptog- 10 raphy.” Zenodo, Apr. 2026. https://doi.org/10.528 1/zenodo.19782168

    2026

  27. [35]

    Module- Lattice-Based Key-Encapsulation Mechanism Standard,

    National Institute of Standards and Technology, “Module- Lattice-Based Key-Encapsulation Mechanism Standard,” NIST FIPS 203, U.S. Department of Commerce, Gaithers- burg, MD, Aug. 2024, doi: 10.6028/NIST.FIPS.203

    2024 doi

  28. [36]

    Rec- ommendations for Key-Encapsulation Mechanisms,

    National Institute of Standards and Technology, “Rec- ommendations 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

    2025 doi

  29. [37]

    Status Report on the Fourth Round of the NIST Post-Quantum Cryptography Standardiza- tion Process,

    G. Alagic et al., “Status Report on the Fourth Round of the NIST Post-Quantum Cryptography Standardiza- tion Process,” NIST Internal Report 8545, U.S. Depart- ment of Commerce, Gaithersburg, MD, Mar. 2025, doi: 10.6028/NIST.IR.8545. 11

    2025 doi

  30. [2024]

    https://nvlpubs.nist.gov/nistpubs/FIPS /NIST.FIPS.203.pdf

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.