{"id":"bf4610be-0d8e-411e-b46d-f99dc21575b9","arxiv_id":"2510.10436","paper_version":2,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":3.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A practical reference that maps post-quantum cryptography from mathematical foundations to deployment, including a taxonomy of six algorithm families, NIST status, and performance data.","lead":"This paper surveys the post-quantum cryptography landscape, organizing six algorithm families and their NIST standardization status, performance, and deployment considerations. It is a reference-style review rather than a new technical result, useful for practitioners planning quantum-safe migrations.","discovery_kind":"review","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Table 2 performance data and §4 prose contradict each other and mix benchmark sources without methodology; the survey's core evidence is unverifiable.","rationale":"The reader's weakest assumption—fidelity of secondary evidence and internal consistency of aggregated numbers—is exactly where the paper is most exposed. The central claim is not a new algorithm or proof but the trustworthiness of a survey snapshot. If Table 2's numbers cannot be reconciled with the prose and the cited sources, then the 'implementation-grounded performance comparison' contribution fails, even though the narrative is broadly consistent with the field's consensus. I do not see a more fundamental flaw: the taxonomy and high-level discussion align with known PQC history and standards, and the paper is transparent about some limitations, including the Table 1 note that many candidates cite the NIST IR rather than primary papers. The contradictions are concrete and checkable, and the mis-citation of [72] is a serious provenance problem. These are fixable with editorial correction and benchmark provenance, which is why a conditional acceptance posture is appropriate rather than rejection. I agree with the reader's identification of the same load-bearing concern and see no need to escalate or downgrade the verdict.","tokens_in":28099,"tokens_out":3039,"duration_ms":27619,"concrete_test":"Extract every numerical cell of Table 2 and compare it against the cited paper's own benchmark table. For the ML-DSA, FALCON, and SLH-DSA rows, check whether §4.1–§4.3 numbers come from the same cited source; then run the three signature schemes on a single machine with a documented CPU, compiler, and optimization level (e.g., SUPERCOP or pqm4) and record median timings. If the reproduced values match one version of the paper's numbers within a stated tolerance, the contradiction is an editorial artifact; if not, the table or prose must be corrected and source/methodology columns added.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central claim—to be a useful, evidence-based practical reference—rests heavily on Table 2 and the prose surrounding it. That evidence is internally inconsistent and not reproducible from the citations. Table 2 reports ML-DSA-65 signing as 1.205 ms, while §4.1 says ML-DSA signs in 0.65 ms; FALCON-512 signing is 0.168 ms in Table 2 but §4.2 says ~3.28 ms; SLH-DSA-128s verification is 1.45 ms in Table 2 but §4.3 says ~3.6 ms. The table aggregates timings from [27], [33], [72], and [29] without a common hardware, compiler, or parameter-set note, so even absent contradictions the performance ordering is not a reliable basis for migration decisions. Separately, [72] (Nguyen et al., a code-based privacy-preserving constructions paper) is repeatedly cited for SPHINCS+/SLH-DSA and the MPC-in-the-Head framework in §2.1.3, §3.3, §3.6, and Table 2; that paper does not appear to be the source of those claims. Because the survey is a synthesis, these are not peripheral details—they are the product. The high-level taxonomy tracks field consensus, but the performance snapshot and citation base need verification before the paper can be used as a practical reference.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"This paper is a survey of post-quantum cryptography (PQC) intended as a practical reference for researchers and practitioners. It proposes a taxonomy of six algorithmic families (lattice-, code-, hash-, multivariate-, isogeny-, and MPC-in-the-Head based), reviews NIST standardization status, presents a performance comparison in Table 2, and discusses hardware acceleration, side-channel security, protocol integration (TLS, DNSSEC), domain-specific deployment (IoT, finance, blockchain), and the relationship between PQC and QKD/QRNGs. The survey's stated contribution is to bridge standards, engineering, and operations, with an emphasis on evidence-based guidance.","tokens_in":28344,"tokens_out":4857,"duration_ms":40093,"significance":"If the data and citations were reliable, this survey would be a useful single-source snapshot of the 2025 PQC ecosystem. Its strengths include a broad scope, a clear taxonomy (though with errors, see below), coverage of implementation security and migration challenges, and a curated open repository (awesome-pqc). The paper also provides explicit discussion of open research problems and domain-specific rollout considerations. However, the survey's value as an evidence-based reference is currently undermined by internal inconsistencies between the prose and Table 2, and by several misattributed citations. These issues are not peripheral because the survey explicitly promises 'implementation-grounded measurements' and 'evidence-based guidance'; they must be corrected before the paper can be used as a practical reference.","major_comments":[{"comment":"The performance numbers in the text and in Table 2 are irreconcilable. §4.1 reports ML-DSA signing in ~0.65 ms and verification in ~0.53 ms, while Table 2 lists ML-DSA-44 at 0.840 ms signing / 0.267 ms verification and ML-DSA-65 at 1.205 ms / 0.398 ms. §4.2 reports Falcon signing at ~3.28 ms and verification near 0.3 ms, while Table 2 lists FALCON-512 at 0.168 ms / 0.036 ms. §4.3 reports SLH-DSA-128s signing near 131 ms and verification around 3.6 ms, while Table 2 lists 120.5 ms / 1.45 ms. Moreover, §4.1 describes these as 'at NIST Security Level 2', but the standardized ML-DSA parameter sets are Levels 1, 3, and 5 (ML-DSA-44, -65, -87). Since the survey's stated value proposition is evidence-based guidance, this internal contradiction is load-bearing and must be resolved by aligning the text and table and by stating which parameter sets and hardware are used.","section":"§4.1, §4.2, §4.3 vs Table 2"},{"comment":"Table 2 aggregates timings from four distinct sources ([27], [33], [72], [29]) without a common hardware platform, compiler, benchmark harness, or parameter-set baseline. The table note only gives units (ms). Without such context, cross-family performance ordering (e.g., ML-KEM vs HQC, FALCON vs SLH-DSA) is not reproducible and cannot support migration recommendations. The survey should either report all measurements on a single, clearly specified platform, or clearly annotate each row with its original environment and reproduce the source numbers consistently.","section":"Table 2 methodology"},{"comment":"Reference [72] (Nguyen et al., 'New code-based privacy-preserving cryptographic constructions') is repeatedly cited for claims it cannot support: §2.1.3 cites it for the SPHINCS+ framework and FORS; §3.3 cites it for SPHINCS+ standardization; §3.6 cites it for MPC-in-the-Head constructions; §3.2 cites it for advanced information set decoding; and Table 2 uses it as the source for SLH-DSA timings. The actual source for SLH-DSA/SPHINCS+ is the SPHINCS+ framework paper (reference [12] in this manuscript), and the MPC-in-the-Head citations should point to the relevant original works (e.g., the MiRitH paper [1] or the PERK paper [13]). These misattributions are load-bearing because the survey's 'comprehensive, evidence-based' claim rests on citation fidelity.","section":"References [72] and related citations"},{"comment":"Table 1 lists CROSS and LESS as 'Multivariate' and HAWK as 'Multivariate' as well. In the NIST additional-signatures context, CROSS is code-based (restricted syndrome decoding), LESS is code-based (linear equivalence), and HAWK is lattice-based (NTRU-like). These are not multivariate schemes. Since a correct taxonomy is a stated core contribution of the paper, these misclassifications undermine the trustworthiness of the classification, and the table should be corrected with accurate family assignments.","section":"Table 1 classification errors"}],"minor_comments":[{"comment":"The SPHINCS+ framework description should cite the SPHINCS+ paper (reference [12]) rather than [72]. Please correct these citations throughout.","section":"§2.1.3, §3.3, §3.6"},{"comment":"The 'information set decoding' passage cites [72]; [72] is not an information-set-decoding reference. A dedicated ISD reference, e.g., the original Prange or modern ISD analyses, should be cited.","section":"§3.2"},{"comment":"The sentence on FPGA implementations cites [29] for lattice-based algorithms, but [29] is an HQC (code-based) hardware implementation. Please provide a lattice-specific citation or adjust the claim.","section":"§5.1"},{"comment":"The name 'SPHINCSLET' should be 'SPHINCSlet' (the area-efficient accelerator for SPHINCS+).","section":"§4.3"},{"comment":"The text mentions 'dual-signature blocks' as a proposed hybrid blockchain approach but does not cite a source. Please add a reference or remove the specific proposal.","section":"§7.4"},{"comment":"The manuscript includes a 'Received 11 October 2025' line in the article header, which is a publisher-inserted field. It should not appear in the author-submitted version.","section":"General"}],"recommendation":"major_revision","confidential_remarks":"The paper has several strengths: it is broad, well-structured, and up to date with NIST's 2024/2025 standardization status. However, the internal data contradictions and the citation misattributions are too severe for acceptance in the current form. The issues are fixable within the scope of the manuscript—by correcting Table 2 and §4, re-checking all [72] citations, and fixing the Table 1 family assignments—so I recommend major revision rather than rejection. I would also suggest that the authors carefully review the reference list for any other mismatches between the cited source and the claims made, and that the performance table report a single, clearly stated measurement environment."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Here's the short version: this is a readable, current survey of the PQC landscape that gets the big picture right, but its own performance data is a mess. The prose in §4 and Table 2 disagree on basic numbers — ML-DSA signing is 0.65 ms in the text and 0.840/1.205 ms in the table; FALCON signing is ~3.28 ms in the text and 0.168 ms in the table; SLH-DSA-128s verification is ~3.6 ms in the text and 1.45 ms in the table. These aren't rounding differences. The table also mixes timings from [27], [33], [72], and [29] with no shared hardware, compiler, or methodology note, so even if the numbers agreed, the comparison wouldn't be reproducible.\n\nWhat the paper does well: the six-family taxonomy is sensible, the coverage of NIST status, protocol integration (TLS, DNSSEC), domain-specific issues, and the QKD/QRNG discussion is broad and current through 2025. The narrative largely matches field consensus. The awesome-pqc repo is a genuinely useful companion.\n\nThe soft spots beyond the data: [72] (Nguyen et al., a code-based privacy paper) is cited for SPHINCS+/SLH-DSA, MPC-in-the-Head, and the SLH-DSA performance rows — that's a systematic citation error. And Table 1 leans on the NIST IR for 11 of 13 candidate schemes; the authors admit this in the note, but it weakens the 'comprehensive' claim. These are fixable, but they're not peripheral in a survey whose product is trust.\n\nBottom line: this is an orientation document for people who want a 2025 map of PQC standards, families, and deployment considerations. It's not yet a reliable source for performance numbers. A competent referee could help reconcile the table and text, fix the citation base, and add provenance for the benchmarks — that's a meaningful revision, not a rewrite. I'd send it out, with the expectation of major corrections.","headline":"A useful 2025 PQC survey whose load-bearing performance data is internally inconsistent — fix the numbers and citations and it's a solid reference.","tokens_in":28960,"tokens_out":2826,"would_cite":false,"duration_ms":24014,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"This survey argues that post-quantum cryptography is best understood as six algorithm families with distinct security and performance profiles, and that lattice- and hash-based schemes should anchor near-term migration, supported by impleme","keywords":["post-quantum cryptography","NIST standardization","lattice-based cryptography","hash-based signatures","hybrid migration","crypto-agility","performance benchmarking","quantum-safe security"],"falsifier":"Re-measure the algorithms on one shared hardware baseline and compare the results to the performance table and the text: the paper itself quotes ML-DSA signing at 0.65 ms versus the table's 0.840 ms, Falcon signing at 3.28 ms versus the table's 0.168 ms, and SLH-DSA verification at 3.6 ms versus the table's 1.45 ms, so the discrepancy is directly checkable.","tokens_in":27906,"feed_emoji":"⚛️","tokens_out":4932,"duration_ms":43587,"temperature":0.7,"pith_summary":"This paper is a survey that attempts to give practitioners a single, evidence-based map of the post-quantum cryptography (PQC) landscape as of 2025. It organizes the field into six algorithm families defined by their hardness assumptions, then assesses each family's security track record, standardization status, and performance. It compares algorithms using implementation-grounded measurements, reviews protocol integration and side-channel resistance, and synthesizes deployment guidance for IoT, finance, cloud, and blockchain. The paper's central claim is that lattice-based schemes are the production-ready anchor, hash-based SLH-DSA is the conservative high-assurance fallback, and hybrid migration with crypto-agility is the necessary operational strategy. A sympathetic reader would care because the survey tries to bridge standards, engineering, and operations in one place, providing a reference orientation for anyone planning a quantum-safe transition.","feed_headline":"Six PQC families, one guide to going quantum-safe","feed_subtitle":"Lattice and hash schemes anchor NIST standards; a new comparison table helps operators plan hybrid rollouts.","key_machinery":"The organizing machinery is the six-family taxonomy, which groups algorithms by underlying hardness problem—LWE/M-LWE for lattices, syndrome decoding for codes, hash preimage and collision resistance, MQ equations, supersingular isogenies, and MPC-in-the-Head zero-knowledge proofs—paired with a comparative performance table built from representative implementation measurements. This two-part apparatus does the work of the survey: it lets the authors explain why lattice and hash schemes won the NIST standards, why code-based HQC remains a fallback, why multivariate and isogeny designs are cautionary, and why deployment must be managed through hybrid and crypto-agility frameworks rather than o","core_discovery":"The paper's claim is that the PQC ecosystem can be productively organized into six families—lattice-based, code-based, hash-based, multivariate, isogeny-based, and MPC-in-the-Head—each defined by a distinct hardness assumption, and that this taxonomy, combined with implementation-level performance measurements and an account of protocol and PKI integration challenges, yields actionable guidance for migration. On the paper's own terms, readers can trust its classification of families, its ordering of performance trade-offs, and its recommendation that near-term deployment center on ML-KEM, ML-DSA, and FN-DSA, with SLH-DSA for high-assurance settings and hybrid classical–post-quantum modes for","pith_inferences":["Inference: A single shared-hardware benchmark suite that reconciles the timings quoted in the text and the performance table would settle the survey's quantitative claims; the qualitative ordering of families would likely survive even if specific numbers change.","Inference: The survey's taxonomy suggests a testable prediction: after NIST's additional-signatures round, newly standardized schemes will come from MPC-in-the-Head and non-structured multivariate families rather than from isogeny-based designs, whose recent breaks the survey treats as decisive.","Inference: The 'harvest now, decrypt later' frame implies that organizations with long-lived secrets—financial records, healthcare data, government archives—should start hybrid PQC deployment before large-scale quantum hardware exists; the survey's own timeline supports this urgency."],"forward_implications":["Practitioners can build near-term quantum-safe systems around ML-KEM, ML-DSA, and FN-DSA, treating these lattice standards as production-ready anchors for key exchange, signing, and verification.","SLH-DSA (SPHINCS+) is the recommended conservative alternative where long-term assurance outweighs speed, at the cost of large signatures (roughly 8–30 KB) and significantly slower signing.","Because post-quantum signatures enlarge handshakes, protocol integration in TLS, DNSSEC, and PKI will require fragmentation strategies, hybrid key exchange, and careful certificate-chain management.","Code-based schemes such as HQC fill the role of providing assumption diversity, while multivariate and isogeny-based families should not be used for critical deployments given recent cryptanalytic breaks.","Crypto-agility and hybrid classical–post-quantum modes are the necessary operational strategy for migration, allowing rollback and interoperability while cryptographic inventories and rotation procedures are built."],"fun_headline_variants":["Six PQC families and how to deploy them","Quantum-safe migration: a six-family field guide","From ML-KEM to SLH-DSA: PQC deployment map","Crypto-agility and hybrid plans: PQC in practice","Six hardness assumptions, one migration roadmap"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The survey's practical value rests on the fidelity of its secondary evidence—that the cited performance numbers and security claims are transcribed and aggregated accurately; if they are not, the evidence base fails even though the qualitative narrative matches field consensus.","fun_headline_variants_meta":{"raw":{"variants":["Six PQC families and how to deploy them","Quantum-safe migration: a six-family field guide","From ML-KEM to SLH-DSA: PQC deployment map","Crypto-agility and hybrid plans: PQC in practice","Six hardness assumptions, one migration roadmap"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000835,"raw_usage":{"total_tokens":3484,"prompt_tokens":752,"completion_tokens":2732,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":496,"completion_tokens_details":{"reasoning_tokens":2655}},"tokens_in":496,"tokens_out":2732,"duration_ms":16195,"temperature":1.0,"reasoning_tokens":2655,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-04T10:16:59.515946+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Re-measure the algorithms on one shared hardware baseline and compare the results to the performance table and the text: the paper itself quotes ML-DSA signing at 0.65 ms versus the table's 0.840 ms, Falcon signing at 3.28 ms versus the table's 0.168 ms, and SLH-DSA verification at 3.6 ms versus the table's 1.45 ms, so the discrepancy is directly checkable.","supporting_citations":[],"review_version":1}