{"id":"ea41d11a-8160-4c2b-94be-f748be440207","arxiv_id":"2608.00954","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"NoisePQC++ is an open C++23 implementation that unifies classical, ML-KEM-based post-quantum, and hybrid Noise handshakes across all 57 classical patterns, 13 PQ patterns, and 12 hybrid patterns, with benchmarks showing manageable overhead.","lead":"An open-source C++23 library, NoisePQC++, adds the NIST-standard ML-KEM post-quantum key exchange, alongside classical ECDH, to the Noise Protocol Framework, covering all 57 classical patterns, 13 post-quantum patterns, and 12 hybrid handshake variants. Why it matters: the benchmarks show quantum-resistant and hybrid Noise handshakes are practical with modest overhead, giving VPN and messaging developers a concrete migration path before quantum computers arrive.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"PQ/HFS conformance rests entirely on self-consistency tests; no independent interop or published PQ test vectors exist, so the all-13-PQ/hybrid coverage claim is not yet externally validated.","rationale":"The reader's weakest assumption correctly identifies the absence of external PQ/HFS validation. My read agrees: the paper has a real engineering artifact, classical test-vector validation, and clear architecture, but no external anchor for the PQ/HFS protocol definitions. The admitted limitation in Section 6.2 is precisely the soft spot. I would keep the CONDITIONAL verdict: interop tests against an independent implementation (or externally published vectors), plus raw benchmark data, should be conditions before the deployment/completeness claims are taken at face value. I did not find an internal logical contradiction in the pattern-count claims: 57 = 15 base + 42 PSK variants, so the absence of fallback patterns does not conflict with 'all 57.' One secondary observation: Figures 4a and 5 appear to report inconsistent CPU/latency values for classical and HFS modes (e.g., Fig 5 shows hybrid CPU lower than classical for XX/IK/KK), which strengthens the need for raw benchmark data, but it is not the primary load-bearing issue.","tokens_in":15928,"tokens_out":17741,"duration_ms":184730,"concrete_test":"Run a cross-implementation interop test: use NoisePQC++ as initiator and Clatter (Rust) or nyquist (Go) as responder for every one of the 13 PQNoise patterns with identical protocol strings (e.g., Noise_pqXX_M768_ChaChaPoly_SHA256), and for at least one hybrid pattern (e.g., XXhfs) if the other library supports it; verify that derived session keys match and a transport AEAD message decrypts. Alternatively, import NoisePQC++'s deterministic seed-based test vectors into the independent implementation and compare transcript hashes/session keys. If any pattern mismatches, the coverage claim must be revised.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim—unified support for all 57 classical, all 13 PQNoise, and hybrid HFS patterns—requires that the implementation's KEM token semantics, protocol-name string, token ordering, and HKDF mixing match the published PQNoise/HFS specifications. That requirement is currently supported only by internal tests. Section 6.2 states 'We have not yet conducted formal interoperability testing with other libraries,' and Section 5.2.3 notes there is no standardized test-vector suite for PQNoise or hybrid patterns; the deterministic vectors are generated by the same implementation. Self-consistency (initiator and responder agree) cannot detect a systematic deviation from the spec, e.g., a wrong ekem/skem placement, a different encoding of the KEM key/ciphertext, or an incorrect order of mixing the two secrets in an HFS pattern. Because the strongest contribution is breadth of pattern coverage, this gap is load-bearing: if the PQ/HFS constructions do not faithfully match the external specs, the 'complete implementation' and deployment-readiness claims fail even though all internal tests pass.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":16130,"tokens_out":7150,"duration_ms":77705,"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":[{"comment":"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,","section":"§6.2, §5.2.3"},{"comment":"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.","section":"Abstract/§1, Fig. 2, Table 2"},{"comment":"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.","section":"§4.2, §5.1.2(d)"}],"minor_comments":[{"comment":"Typo: 'A VX2' should be 'AVX2'.","section":"§3.2"},{"comment":"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.","section":"Table 2"},{"comment":"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.","section":"§6.3, Fig. 5"},{"comment":"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.","section":"§4.2"},{"comment":"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.'","section":"§6.2"}],"recommendation":"major_revision","confidential_remarks":"This is a well-structured systems paper with a useful artifact and credible performance data. The main concern is external validation: the PQ and HFS conformance claims are currently supported only by self-generated tests and self-consistency. An interop test against one independent implementation, or cross-generated reference vectors, would substantially increase confidence. The HFS pattern-count inconsistency should be fixed before acceptance. The paper fits the venue well; I would not reject on the current evidence, but the load-bearing validation gap needs to be closed."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Read NoisePQC++. The core artifact is real: a single C++23 codebase covering all 57 classical Noise patterns, the 13 PQNoise patterns, and HFS hybrids, with ML-KEM-512/768/1024 behind one API. That breadth is new relative to Clatter and the SecITC prototype, and the classical patterns are checked against official Noise test vectors. The architecture is sensible: ECDH and KEM unified behind a Dh interface, HKDF mixing in token order, debug instrumentation that stays out of release builds. Public code with Docker and Zenodo makes it reproducible. This is a genuine engineering contribution for anyone wanting to experiment with PQ Noise without wiring together several prototypes.\n\nThe soft spots are where the reader put them. Section 6.2 says there has been no formal interoperability testing with other libraries. That matters because PQ and HFS correctness is validated only by deterministic vectors generated by the same implementation. Self-consistency between initiator and responder cannot catch a systematic misreading of ekem/skem placement, KEM encoding, or secret-mixing order in the HFS patterns. The stress-test note is right: this gap is load-bearing for the 'complete implementation' claim. It is not fatal to the paper's engineering value, but the deployment-readiness language in the abstract and Section 6.4 goes further than the evidence. The performance evaluation also lacks error bars and variance detail; figures are single averages, and the claim that ML-KEM-768 beats X25519 is plausible but needs raw data and repetition.\n\nMinor issues: Table 2's feature comparison leans generous to the authors and slightly harsh on Clatter; the PSK and deferred-pattern coverage for PQ and HFS is asserted without external reference. The benchmark section is descriptive rather than statistically careful, but consistent with prior work.\n\nWho is this for? Anyone implementing or evaluating PQ Noise libraries: protocol integrators, researchers benchmarking handshake overhead, and people building hybrid VPN or messaging prototypes. It deserves a serious referee. The main revision should be interop tests against Clatter or another independent library, plus published raw benchmark data. With those, the deployment claims become credible.","headline":"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.","tokens_in":16608,"tokens_out":1474,"would_cite":true,"duration_ms":16743,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Single handshake engine runs all Noise patterns with ML-KEM","keywords":["post-quantum cryptography","Noise Protocol Framework","ML-KEM","hybrid key exchange","hybrid forward secrecy","handshake patterns","C++23 implementation","key encapsulation mechanism"],"falsifier":"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.","tokens_in":1559,"feed_emoji":"🔐","tokens_out":2863,"duration_ms":95269,"temperature":0.7,"pith_summary":"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.","feed_headline":"Noise handshakes run classical, PQC, and hybrid in one engine","feed_subtitle":"ML-KEM-only handshakes beat X25519 on speed; hybrid costs about 1.25 to 1.70 times the classical latency.","key_machinery":"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.","core_discovery":"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","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Defines the PQNoise ekem and skem tokens and the security model used for pure-PQ handshakes.","marker":"[7]"},{"why":"Defines the hybrid e1 and ekem1 tokens and the HFS construction the hfs patterns follow.","marker":"[11]"},{"why":"Supplies the ML-KEM-512/768/1024 standard used as the post-quantum primitive.","marker":"[12]"},{"why":"Defines the Noise token semantics, the 57 classical pattern variants, and the MixKey/MixHash machinery.","marker":"[13]"},{"why":"A performance study of PQ and hybrid Noise on constrained devices that this work extends to broader pattern coverage.","marker":"[8]"},{"why":"A prior PQ-capable Noise implementation used as the main feature-coverage comparison baseline.","marker":"[9]"},{"why":"Official Noise test vectors used to cross-check correctness of the classical handshakes.","marker":"[22]"}],"fun_headline_variants":["One engine runs classical, PQC, and hybrid Noise handshakes","ML-KEM makes Noise handshakes 15-34% faster than ECDH","Hybrid Noise PQC costs 1.25-1.70x classical latency","NoisePQC++ brings NIST ML-KEM to all 57 handshake patterns"],"cache_read_input_tokens":18560,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["One engine runs classical, PQC, and hybrid Noise handshakes","ML-KEM makes Noise handshakes 15-34% faster than ECDH","Hybrid Noise PQC costs 1.25-1.70x classical latency","NoisePQC++ brings NIST ML-KEM to all 57 handshake patterns"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000838,"raw_usage":{"total_tokens":3525,"prompt_tokens":816,"completion_tokens":2709,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":560,"completion_tokens_details":{"reasoning_tokens":2619}},"tokens_in":560,"tokens_out":2709,"duration_ms":20037,"temperature":1.0,"reasoning_tokens":2619,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T00:34:29.509064+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"Post quantum noise,","cited_arxiv_id":null,"evidence_quote":"Defines the PQNoise ekem and skem tokens and the security model used for pure-PQ handshakes."},{"cited_title":"KEM-based Hybrid Forward Secrecy for Noise","cited_arxiv_id":null,"evidence_quote":"Defines the hybrid e1 and ekem1 tokens and the HFS construction the hfs patterns follow."},{"cited_title":"Module-lattice-based key-encapsulation mechanism stan- dard,","cited_arxiv_id":null,"evidence_quote":"Supplies the ML-KEM-512/768/1024 standard used as the post-quantum primitive."},{"cited_title":"The Noise Protocol Framework","cited_arxiv_id":null,"evidence_quote":"Defines the Noise token semantics, the 57 classical pattern variants, and the MixKey/MixHash machinery."},{"cited_title":"An evaluation of post-quantum and hybrid noise protocol variants on mobile devices,","cited_arxiv_id":null,"evidence_quote":"A performance study of PQ and hybrid Noise on constrained devices that this work extends to broader pattern coverage."},{"cited_title":"Jmlepisto/clatter","cited_arxiv_id":null,"evidence_quote":"A prior PQ-capable Noise implementation used as the main feature-coverage comparison baseline."},{"cited_title":"Test vectors","cited_arxiv_id":null,"evidence_quote":"Official Noise test vectors used to cross-check correctness of the classical handshakes."}],"review_version":1}