{"id":"46bdaf30-9096-4eb3-abf7-22b7a7482f75","arxiv_id":"2508.16078","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":3.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A survey of nine open-source crypto libraries shows uneven support for NIST's post-quantum algorithms as of early 2025.","lead":"This paper surveys nine open-source cryptographic libraries to see which already support the NIST post-quantum algorithms. It finds a mixed picture: Bouncy Castle and wolfSSL are ahead, OpenSSL and MbedTLS are still integrating, and libsodium and LibreSSL lag.","discovery_kind":"review","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The readiness matrix is the load-bearing evidence for the paper's conclusion, but it depends on an arbitrary early-2025 cutoff and on 'silence means no support' inferences, and it is internally inconsistent (Table 1 marks OpenSSL 'Yes' while §5.1 says 'not yet in mainline').","rationale":"Read in good faith, the paper is a snapshot survey, not a research result with a new theorem. The strongest claim is that the nine libraries show uneven PQC progress, and that claim is supported by the per-library matrix. The reader's weakest-assumption analysis correctly identifies the two fragilities: the early-2025 cutoff and the reliance on absence of public announcements. I agree, and the paper's own footnotes make the cutoff problem concrete—OpenSSL 3.5 shipped PQC in April 2025, between the nominal snapshot and the compilation date, yet the main text still says OpenSSL does not officially support PQC. In addition, the internal inconsistency between Table 1 and §5.1 on OpenSSL's status shows that the matrix is not even reproducible from the paper's own text without interpretation. The broad conclusion of uneven progress is very likely correct—several rows (Bouncy Castle, wolfSSL, Botan) are backed by cited releases and independent reports—so this is not a reason to reject the paper. But for a survey whose practical value is telling adopters which libraries are ready, the matrix must be accurate, current, and reproducible. The conditional is therefore appropriate: the paper should version its snapshot, reconcile Table 1 with the text, and replace absence-of-evidence inferences with explicit checks of the relevant repositories and release notes.","tokens_in":18024,"tokens_out":6542,"duration_ms":70284,"concrete_test":"Pin all nine libraries to their release tags as of the manuscript's compilation date (2025-09-23). For each, grep the source tree and official release notes for ML-KEM/Kyber, ML-DSA/Dilithium, FALCON, and SLH-DSA/SPHINCS+, and re-derive Table 1 with a three-way stable/experimental/absent column. Specifically check OpenSSL 3.5's default providers, MbedTLS's mlkem-native integration status, LibreSSL's current branch and mailing lists, and Crypto++'s release history. If OpenSSL/MbedTLS show ML-KEM and any 'No' library shows code, revise the affected rows and restate the conclusion with an explicit snapshot date; if the revised matrix preserves the same haves/have-nots, the central claim survives.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"The central claim—'a landscape of uneven progress'—is carried almost entirely by Table 1's per-library classification of NIST PQC support. That classification is not robust for two reasons. First, it relies on a fixed 'early 2025' snapshot that the paper itself contradicts: the footnote to §5.1 and §7 states that OpenSSL 3.5 shipped ML-KEM/ML-DSA in April 2025, after the nominal cutoff, making OpenSSL the paper's most important 'not yet supporting' example already stale at compilation time (September 2025). Second, negative statuses are inferred from absence of evidence: §5.9 declares LibreSSL has 'none yet' because no public announcement was found, and §5.4 infers Crypto++ has no official PQC support because it is absent from mainline. Silence in public sources is weak evidence for a negative claim about fast-moving open-source projects, especially when development branches and unannounced forks can exist. The internal inconsistency compounds this: Table 1 lists OpenSSL as 'Yes' for NIST PQC while §5.1 says 'in development, not yet in mainline'; MbedTLS is 'Partial' because it supports LMS, a standardized PQC scheme, even though §5.3 says it lacks all four finalists. If any of the 'No' libraries in fact has support in a development branch or in a release between the snapshot and compilation, the paper's readiness landscape changes for those specific libraries.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper surveys nine widely used open-source cryptographic libraries (OpenSSL, wolfSSL, BoringSSL, LibreSSL, Bouncy Castle, libsodium, Crypto++, Botan, MbedTLS) for their support of the NIST post-quantum finalists (Kyber/ML-KEM, Dilithium/ML-DSA, FALCON, SPHINCS+) as of early 2025. It ranks libraries using GitHub forks/stars, evaluates each library against consistent criteria, presents a support matrix (Table 1), and discusses real-world use cases in government, web, enterprise, and IoT settings. The central claim, stated in Section 7, is that the nine libraries reveal a landscape of uneven progress, with some libraries already offering production PQC and others lagging. The paper also discusses implementation challenges, including performance, side-channel security, and crypto agility.","tokens_in":18339,"tokens_out":3852,"duration_ms":43690,"significance":"If made internally consistent and current, this survey would be a useful practical reference for practitioners planning PQC migration, since it consolidates primary sources from library release notes, maintainer statements, and the PKI Consortium's PQC matrix. Strengths include the systematic library selection, the explicit evaluation criteria in Section 4.2, the attention to production deployments such as Chrome/BoringSSL and wolfSSL, and the discussion of non-finalist schemes like LMS/XMSS. However, the current version contains load-bearing internal contradictions and relies on absence-of-evidence for several negative classifications, so the readiness matrix cannot yet be considered a reliable basis for the paper's conclusion.","major_comments":[{"comment":"There is a direct internal contradiction in the core readiness matrix. Table 1 gives OpenSSL a 'Yes' for 'Supports NIST PQC', but §5.1 states the status is 'in development, not yet in mainline', and the table row also lists a roadmap with no entry. The footnote to §5.1 (and the footnote in §7) says OpenSSL 3.5 launched in April 2025 with PQC. The paper must reconcile these: either the survey's snapshot is early 2025 and OpenSSL is correctly 'No' at that cutoff, or the survey is current to its September 2025 compilation and OpenSSL must be listed as supporting ML-KEM/ML-DSA in 3.5. As written, the paper's most important example is internally inconsistent.","section":"Table 1 vs. §5.1"},{"comment":"The abstract and Section 2 state the analysis reflects the state 'as of early 2025', yet the manuscript is compiled in September 2025 and the footnotes acknowledge the April 2025 OpenSSL 3.5 release. This makes the reported snapshot already stale at the stated compilation date, and the conclusion in Section 7 repeats 'does not officially support PQC as of early 2025' while the footnote immediately after says OpenSSL 3.5 includes PQC. Please update all statuses to a single clearly stated cutoff date, or explicitly separate an 'early 2025 snapshot' from a 'current as of compilation' update. The current presentation will mislead readers about OpenSSL's present-day readiness.","section":"§2/§7 and footnotes 1 and 2"},{"comment":"The negative classifications for LibreSSL and Crypto++ are inferred from the absence of evidence. Section 5.9 concludes 'none yet' for LibreSSL because release notes through 3.8/3.9 made no mention of PQC, and Section 5.4 infers Crypto++ has no official PQC support because it is absent from mainline. Silence in public sources is weak evidence for a negative claim about fast-moving open-source projects, as development branches and unannounced efforts may exist. The paper should either provide positive evidence (maintainer statements, issue-tracker responses, absence after explicit search) or phrase these entries as 'no public support found at cutoff' and temper the corresponding conclusions about lagging libraries.","section":"§5.9 and §5.4"},{"comment":"The table lists MbedTLS as 'Partial' for NIST PQC, but Section 5.3 explicitly says MbedTLS has none of the four NIST finalists (Kyber, Dilithium, FALCON, SPHINCS+). The 'Partial' appears to derive from LMS support, which is an alternate PQC signature scheme. This conflates two different criteria. Under the paper's stated criterion 1 ('Does the library support any of the NIST PQC finalist algorithms?'), MbedTLS should be 'No' for finalist support, with LMS noted separately. The same ambiguity affects the BoringSSL 'Partial' row and should be clarified by defining the table's status levels.","section":"Table 1, MbedTLS row"}],"minor_comments":[{"comment":"The column 'PQC Forks Exist' is not defined in the text. It is not clear how it is determined (e.g., third-party forks like cryptopp-pqc, OQS provider branches) or why OpenSSL and MbedTLS have 'Yes' while Bouncy Castle and wolfSSL have 'No'. Add a legend or a definition.","section":"Table 1"},{"comment":"The statement that libsodium's latest release is in the '1.0.x series' is vague; give the specific version number and date, and check whether the ML-KEM roadmap statement from discussion #1275 has evolved by the paper's compilation date.","section":"§5.2"},{"comment":"The Botan section says FALCON was not yet supported at the time of the PQC matrix update, but this is cited to an external matrix rather than to current Botan release notes. Please verify against Botan 3.x release notes and state the verification date.","section":"§5.7"},{"comment":"Figures 1, 2, and 3 are referenced in the text, but in the supplied manuscript no figure images appear, only captions. Verify that the final PDF includes the actual figures.","section":"Figures"},{"comment":"The GitHub star/fork ranking method is described but the resulting ranks are not tabulated or justified. Since the survey claims to rank the nine libraries, a small table with star/fork counts and ranks would improve reproducibility.","section":"§4.1"}],"recommendation":"major_revision","confidential_remarks":"This is a descriptive survey, so the main issue is not technical derivation but internal consistency and the validity of negative inferences. The internal OpenSSL contradiction and the stale snapshot are fixable with an update pass and clearer scoping, so I do not recommend rejection. The paper should be checked for whether the OpenSSL 3.5 release (April 2025) and any other post-cutoff changes materially alter the readiness matrix before resubmission."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nThis paper is a practitioner survey, not a research result. The substance is the nine-library readiness table and the narrative around it. If you need a quick map of who supports Kyber/Dilithium etc. as of early 2025, this is a reasonable place to start. The authors cite the PKI Consortium matrix and prior TLS surveys honestly, and they add value by weaving in project-specific details — MbedTLS's LMS support, the OQS provider, Bouncy Castle's early PQC API, Chrome's Kyber rollout. The KyberSlash discussion and performance notes are useful context. I believe the central claim, that readiness is uneven, is clearly true.\n\nThe soft spots are real but not fatal. The paper has an internal contradiction about OpenSSL: Section 5.1 and the conclusion say OpenSSL has no official PQC support as of early 2025, while footnote 1 and the footnote in Section 7 say OpenSSL 3.5 shipped ML-KEM/ML-DSA in April 2025. The paper was compiled in September 2025, so the snapshot is stale on its most important example. A reader can reconcile the two statements by reading the footnotes, but the main text should not be left contradicting them. Also, several \"no support\" verdicts — LibreSSL and Crypto++ mainly — are inferred from absence of announcements. That is weak evidence for fast-moving open-source projects, and the paper should label these as \"no public support found\" rather than \"none yet.\" The ranking by stars times forks is ad hoc and does not really matter for the survey's conclusions; I would treat it as decoration.\n\nWho is this for? Developers and security engineers planning PQC migration who want a targeted overview of these nine libraries. A researcher will not learn much beyond what the PKI Consortium matrix and prior surveys already say. With a corrected OpenSSL status, a dated snapshot, and less confidence in absence-based negatives, I would be comfortable sending this to peer review as a survey. Without those fixes, the main table could mislead.\n\nRecommendation: do not desk reject, but the reviewers should insist on the corrections above.","headline":"A useful but already stale snapshot of PQC library support; fix the OpenSSL inconsistency and version the cutoff before relying on it.","tokens_in":18803,"tokens_out":1912,"would_cite":false,"duration_ms":21317,"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":"As of early 2025, support for NIST post-quantum algorithms across nine major open-source crypto libraries is uneven: four are production-ready, others have none.","keywords":["post-quantum cryptography","open-source cryptographic libraries","NIST PQC standards","ML-KEM (Kyber)","ML-DSA (Dilithium)","quantum readiness","TLS 1.3","crypto agility"],"falsifier":"Inspect the source trees of the latest stable release of each of the nine libraries for implementations of ML-KEM, ML-DSA, FALCON, and SLH-DSA (search for the algorithm names or NIST identifiers). The survey predicts those implementations appear only in wolfSSL, Bouncy Castle, Botan, and BoringSSL, with LMS/XMSS additionally in wolfSSL and MbedTLS; finding such code in libsodium, Crypto++, LibreSSL, or mainline OpenSSL would refute the 'no support' verdicts, just as finding none in a library called production-ready would refute the ready verdicts.","tokens_in":17915,"feed_emoji":"⚛️","tokens_out":16736,"duration_ms":158371,"temperature":0.7,"pith_summary":"This paper asks whether the open-source cryptographic libraries that secure the internet, its software supply chains, and embedded devices are ready for the shift to post-quantum cryptography. It examines nine widely used libraries—OpenSSL, wolfSSL, BoringSSL, LibreSSL, Bouncy Castle, libsodium, Crypto++, Botan, and MbedTLS—against the NIST-standardized algorithms: ML-KEM (Kyber) for key exchange, and ML-DSA (Dilithium), FALCON, and SLH-DSA (SPHINCS+) for signatures, using documentation, release notes, and industry reports current to early 2025. The central finding is a landscape of uneven progress: wolfSSL, Bouncy Castle, Botan, and BoringSSL offer working PQC, while OpenSSL (at the cutoff), MbedTLS, libsodium, Crypto++, and LibreSSL had little or none. The authors' larger point is that readiness is a spectrum rather than a binary, and that the laggards sit among intentionally conservative or minimalist libraries. If the survey is right, a quantum-safe migration is possible today but only with careful library selection, and the gaps will shape whether the 2025–2035 government transition deadlines can be met.","feed_headline":"Only four of nine top crypto libraries ship post-quantum algorithms","feed_subtitle":"The gap matters for the 2035 quantum-ready deadline: some libraries are ready today, others have no roadmap.","key_machinery":"The survey's yardstick is the set of algorithms NIST selected for standardization in 2022: CRYSTALS-Kyber, now ML-KEM, for key establishment, and CRYSTALS-Dilithium (ML-DSA), FALCON, and SPHINCS+ (SLH-DSA) for signatures. Each library is checked against five criteria—whether it supports any of the finalists, since which version that support is stable or experimental, whether a roadmap exists, whether alternative PQC schemes (stateful LMS/XMSS, code-based schemes) are present, and whether support is in a production release or only a development branch. The argument is carried by the resulting readiness matrix, which compresses documentation, release notes, and vendor announcements for nine li","core_discovery":"Readiness splits into three tiers. wolfSSL ships ML-KEM and ML-DSA in TLS plus LMS/XMSS and claims CNSA 2.0 compliance; Bouncy Castle implements all four NIST finalists and many alternates; Botan ships Kyber, Dilithium, SPHINCS+, and XMSS; BoringSSL took ML-KEM and ML-DSA to production through Chrome's hybrid X25519+Kyber exchange. At the other end, libsodium has no PQC despite community interest, Crypto++ and LibreSSL have neither support nor a stated roadmap, and MbedTLS offers only stateful LMS while planning ML-KEM first. OpenSSL sits in the middle: no mainline PQC at the early-2025 cutoff, but an announced roadmap, an external-provider option, and—per the paper's own footnote—a 3.5 rele","pith_inferences":["The paper's own footnote makes the snapshot's shelf life visible: OpenSSL 3.5 shipped PQC in April 2025, so by the September 2025 compilation date the 'transitional' tier is already smaller than the survey's conclusion states; re-running the survey now would likely move OpenSSL into the ready tier, leaving the same three laggards.","The adoption pattern tracks library philosophy more than size: the ready libraries are the comprehensive APIs and the embedded-market specialist, while the laggards are the minimalists and the FIPS-leaning C++ library; whether a minimalist library can absorb complex lattice primitives without breaking its design is a question the paper leaves open.","Because several verdicts rest on the absence of public announcements, a direct source-code audit of each library's current release—rather than its documentation—would convert those verdicts from inference to fact and is cheap enough to run as a follow-up check."],"forward_implications":["An organization that needs PQC today can already ship it in production with wolfSSL, Bouncy Castle, Botan, or BoringSSL, without waiting for the broader ecosystem.","When OpenSSL 3.5 (recorded in the paper's footnote as released in April 2025) propagates, the most widely used TLS library will natively support the NIST algorithms, making Kyber key exchange and Dilithium signatures available to mainstream server deployments.","MbedTLS's existing LMS support lets IoT firmware signing become quantum-resistant now, but embedded TLS handshakes remain classical until ML-KEM is added.","Projects built on libsodium, Crypto++, or LibreSSL have no in-library PQC path at the snapshot date, forcing them to add a second library or delay their migration.","The uneven landscape means the 2035 US government transition deadline will require targeted work on the lagging libraries, not just automatic adoption of standards."],"supporting_citations":[{"why":"NIST's July 2022 announcement selecting Kyber, Dilithium, FALCON, and SPHINCS+ — defines the algorithm set that the survey uses as its yardstick for every library.","marker":"[6]"},{"why":"OpenSSL Foundation's September 2024 statement of intent to implement the NIST finalists — the core evidence for OpenSSL's transitional status at the cutoff.","marker":"[19]"},{"why":"Sosnowski et al.'s TLS 1.3 performance study — grounds the survey's claim that PQC adoption faces no insurmountable performance barrier.","marker":"[28]"},{"why":"Google's announcement that ML-KEM shipped in the BoringSSL/Chrome stack — evidence that production-grade PQC deployment already works at scale.","marker":"[29]"},{"why":"The PKI Consortium's PQC Capabilities Matrix — the baseline support data that the survey verifies and enriches with stability and roadmap detail.","marker":"[31]"},{"why":"The libsodium maintainer discussion — evidence that no NIST finalist is implemented and that ML-KEM is only a tentative roadmap item.","marker":"[37]"},{"why":"MbedTLS developer forum reply — evidence that ML-KEM will come first, with LMS already supported for signatures.","marker":"[38]"},{"why":"Bouncy Castle's post-quantum update — evidence that all four NIST finalists and many alternates are supported in the Java/C# library.","marker":"[42]"},{"why":"wolfSSL's Embedded World 2025 release — evidence that ML-KEM and ML-DSA are shipped in production with a CNSA 2.0 compliance claim.","marker":"[45]"}],"fun_headline_variants":["5 of 9 crypto libraries lack post-quantum algorithms","Only 4 of 9 top crypto libraries ship PQC today","Quantum-ready: just 4 of 9 libraries, others lag","Post-quantum gap: 5 libraries no support, no roadmap","Crypto libraries uneven for quantum era: 4 ready, 5 not"],"cache_read_input_tokens":2688,"weakest_assumption_plain":"The survey assumes its early-2025 snapshot is both current and complete — that no public announcement means no support and no roadmap — an assumption its own footnote undercuts: OpenSSL 3.5 shipped PQC in April 2025, months before the paper's September 2025 compilation date.","fun_headline_variants_meta":{"raw":{"variants":["5 of 9 crypto libraries lack post-quantum algorithms","Only 4 of 9 top crypto libraries ship PQC today","Quantum-ready: just 4 of 9 libraries, others lag","Post-quantum gap: 5 libraries no support, no roadmap","Crypto libraries uneven for quantum era: 4 ready, 5 not"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000751,"raw_usage":{"total_tokens":3199,"prompt_tokens":782,"completion_tokens":2417,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":526,"completion_tokens_details":{"reasoning_tokens":2324}},"tokens_in":526,"tokens_out":2417,"duration_ms":20559,"temperature":1.0,"reasoning_tokens":2324,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-05T17:31:33.425118+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Inspect the source trees of the latest stable release of each of the nine libraries for implementations of ML-KEM, ML-DSA, FALCON, and SLH-DSA (search for the algorithm names or NIST identifiers). The survey predicts those implementations appear only in wolfSSL, Bouncy Castle, Botan, and BoringSSL, with LMS/XMSS additionally in wolfSSL and MbedTLS; finding such code in libsodium, Crypto++, LibreSSL, or mainline OpenSSL would refute the 'no support' verdicts, just as finding none in a library called production-ready would refute the ready verdicts.","supporting_citations":[{"cited_title":"NIST Announces First Four Quantum-Resistant Cryptographic Algorithms","cited_arxiv_id":null,"evidence_quote":"NIST's July 2022 announcement selecting Kyber, Dilithium, FALCON, and SPHINCS+ — defines the algorithm set that the survey uses as its yardstick for every library."},{"cited_title":"Post-Quantum Algorithms in OpenSSL","cited_arxiv_id":null,"evidence_quote":"OpenSSL Foundation's September 2024 statement of intent to implement the NIST finalists — the core evidence for OpenSSL's transitional status at the cutoff."},{"cited_title":"The performance of post-quantum TLS 1.3,","cited_arxiv_id":null,"evidence_quote":"Sosnowski et al.'s TLS 1.3 performance study — grounds the survey's claim that PQC adoption faces no insurmountable performance barrier."},{"cited_title":"A new path for Kyber on the web","cited_arxiv_id":null,"evidence_quote":"Google's announcement that ML-KEM shipped in the BoringSSL/Chrome stack — evidence that production-grade PQC deployment already works at scale."},{"cited_title":"PQC Capabilities Matrix (PQCCM)","cited_arxiv_id":null,"evidence_quote":"The PKI Consortium's PQC Capabilities Matrix — the baseline support data that the survey verifies and enriches with stability and roadmap detail."},{"cited_title":"Post quantum cryptography · jedisct1/libsodium · Discussion #1275","cited_arxiv_id":null,"evidence_quote":"The libsodium maintainer discussion — evidence that no NIST finalist is implemented and that ML-KEM is only a tentative roadmap item."},{"cited_title":"Mbedtls and PQC algorithms support - mbed-tls - lists.trustedfirmware.org","cited_arxiv_id":null,"evidence_quote":"MbedTLS developer forum reply — evidence that ML-KEM will come first, with LMS already supported for signatures."},{"cited_title":"Post-Quantum Algorithm Update in Bouncy Cas- tle","cited_arxiv_id":null,"evidence_quote":"Bouncy Castle's post-quantum update — evidence that all four NIST finalists and many alternates are supported in the Java/C# library."},{"cited_title":"wolfSSL Unveils Post Quantum Cryptography and Security Solutions at Embedded World 2025 – wolfSSL","cited_arxiv_id":null,"evidence_quote":"wolfSSL's Embedded World 2025 release — evidence that ML-KEM and ML-DSA are shipped in production with a CNSA 2.0 compliance claim."}],"review_version":1}