What NIST IR 8610 Third Round PQC Candidates Mean for Security

Key Takeaways

• NIST IR 8610 reports on round two of the Additional Digital Signatures process and selects nine candidates for round three: FAEST, MQOM, SDitH, HAWK, SQIsign, UOV, MAYO, QR-UOV, and SNOVA.
• HAWK was withdrawn from the process on July 29, 2026, after a key recovery attack cut its estimated security margin, leaving eight active round three candidates as of this update.
• The finalized, migration-ready standards remain ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205), all published August 14, 2024, plus FN-DSA (FIPS 206), which is still in draft.
• Round three candidates are backups for algorithm diversity and constrained environments. They do not change the current migration priority or any CNSA 2.0 deadline.
• Before touching signature algorithms, security architects need a cryptographic inventory, a phased migration plan, interoperability and performance testing evidence, and a documented crypto agility design.

Published: May 2026. Updated: August 2026. Reviewed by Encryption Consulting’s PQC advisory team.

What Is NIST IR 8610, and What Do the Third Round PQC Candidates Mean?

On May 14, 2026, NIST published NIST IR 8610, formally titled “Status Report on the Second Round of the Additional Digital Signature Schemes for the NIST Post-Quantum Cryptography Standardization Process.” Despite the name, the report’s practical effect is to select which candidates move into round three: nine signature schemes drawn from four mathematical families advanced, after 18 months of evaluation and the elimination of five second-round candidates.

This is a separate, later NIST process from the one that produced ML-DSA (FIPS 204) and SLH-DSA (FIPS 205). Those two standards, along with ML-KEM (FIPS 203), came out of the original PQC standardization competition, documented in NISTIR 8413, “Status Report on the Third Round of the NIST Post-Quantum Cryptography Standardization Process,” published in 2022. NIST IR 8610 covers a different, purpose-built competition called Additional Digital Signatures, launched in September 2022 specifically to find backup signature schemes that do not depend on structured lattice assumptions. If you want a plain-language walkthrough of the nine candidates themselves, see our companion explainer, NIST IR 8610 Explained. This article focuses on what the report means for security architects running an active or planned PQC migration: standards status, inventory prerequisites, algorithm caveats, migration steps, testing evidence, and an implementation checklist.

What Are the Current NIST PQC Standards and Deadlines?

Three post-quantum standards are finalized and available for production use today. NIST published FIPS 203, FIPS 204, and FIPS 205 on August 14, 2024. ML-KEM (FIPS 203) handles key encapsulation for encryption and key exchange. ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) handle digital signatures. A fourth standard, FN-DSA (FIPS 206), based on the Falcon algorithm, is still in draft, with NIST targeting a draft approval and final publication in late 2026 or 2027; see our FN-DSA (FIPS 206) explainer for the current draft status.

Standard	Algorithm	Type	Public Key Size	Signature or Ciphertext Size	Primary Use Case
FIPS 203	ML-KEM-768	Key encapsulation mechanism	Approximately 1,184 bytes	Approximately 1,088 bytes (ciphertext)	TLS key establishment, VPNs, general encryption key exchange
FIPS 204	ML-DSA-65	Digital signature	Approximately 1,952 bytes	Approximately 3,309 bytes	General-purpose signing, certificates, code signing
FIPS 205	SLH-DSA-SHA2-128s	Digital signature	32 bytes	7,856 to 17,088 bytes, depending on variant	Long-lived signatures, root CA and firmware signing, independent backup to lattice schemes

Deadlines depend on which regulatory track applies. For U.S. National Security Systems, the NSA’s Commercial National Security Algorithm Suite 2.0 (CNSA 2.0, issued September 2022) requires ML-KEM-1024 and ML-DSA-87, with new systems expected to support CNSA 2.0 starting in 2027 and full transition timelines running through 2030 to 2033 depending on system category. For civilian and commercial systems, NIST IR 8547 lays out the transition roadmap: RSA and elliptic curve algorithms are expected to be deprecated around 2030 and disallowed around 2035. Neither timeline is affected by the round three additional signature candidates in NIST IR 8610. Those candidates are years away from standardization and are not a substitute for the finalized standards above.

Why Did NIST Launch a Second Track for Additional Signatures?

ML-DSA and FN-DSA are both structured-lattice schemes. ML-DSA rests on the assumed hardness of Module-LWE and Module-SIS problems. FN-DSA draws its security from finding short vectors in NTRU lattices. They share a mathematical family while relying on distinct hardness assumptions. SLH-DSA is hash-based, an independent security foundation, but at a real performance cost: SLH-DSA-SHA2-128s produces signatures ranging from 7,856 bytes in the compact variant up to 17,088 bytes in the fast variant, as shown in the table above.

If a cryptanalytic breakthrough compromised structured lattice assumptions, classically or with a sufficiently capable quantum computer, two of NIST’s three finalized signature standards would fall simultaneously, leaving SLH-DSA as the only remaining option in a role it was never designed to carry alone. History gives this concern real weight. Rainbow, a multivariate signature scheme that reached the finalist stage of the original NIST PQC process, was broken in 2022 following a cryptanalytic advance that caught the community by surprise. SIKE, an isogeny-based key encapsulation mechanism, was broken the same year during round four of the original process using a classical attack by Castryck and Decru. Lattice cryptography has been studied more extensively than either of those schemes, but concentrating trust in one mathematical family is still a risk NIST wanted a hedge against.

There is also a concrete performance problem. ML-DSA-44 (Category 2) produces 2,420-byte signatures. FN-DSA-512 produces approximately 666 bytes per the current Falcon specification. Compare those to the 64 bytes of ECDSA P-256 (71 to 72 bytes DER-encoded), and the size increase from migrating to post-quantum signatures becomes concrete. For high-bandwidth TLS and general code signing, these sizes are manageable if inconvenient. For DNSSEC, whose validation chains stack signatures through root, TLD, and second-level domain records and were engineered around 512-byte UDP packets, ML-DSA signatures push nearly every response into connection-oriented transport. Constrained IoT and OT environments, running legacy fieldbus protocols, 8-bit microcontrollers, and safety-critical control systems with tight timing requirements, face the same problem from a different angle: a several-kilobyte signature appended to every command is not a performance optimization to skip, it is a deployment blocker.

NIST’s Call for Additional Digital Signatures, issued in September 2022, was explicit about both motivations, algorithm diversity and compact signatures for constrained environments. The process received 50 submissions, accepted 40 into the first round, advanced 14 to the second round, and selected nine for the third via NIST IR 8610.

Which Candidates Advanced to Round Three, and What Happened to HAWK?

NIST IR 8610 selected nine candidates spanning four mathematical families. Each family brings a different hardness assumption to the table, and that diversity is the point: a breakthrough against one family leaves the others standing. One of the nine has since been withdrawn. The table below reflects status as of this update, organized by mathematical family so the structural relationships between candidates are visible at a glance.

Algorithm	Family	Round 3 Status	Key Advantage	Key Tradeoff
FAEST	MPC-in-the-Head (VOLEitH)	Active	Security relies primarily on well-established symmetric primitives (AES); NIST stated the highest confidence in FAEST’s security assumptions of any MPCitH candidate	Complex design and recently updated security proofs require continued community verification
MQOM	MPC-in-the-Head (TCitH)	Active	Smallest combined public key and signature sizes among MPCitH candidates at all three security levels	Random Oracle Model and Quantum Random Oracle Model security proofs are still maturing
SDitH	MPC-in-the-Head (VOLEitH)	Active	Security based on the syndrome decoding problem for unstructured linear codes, studied since the 1970s	Slower than its MPCitH peers
HAWK	Lattice-based	Withdrawn (July 29, 2026)	Was the only lattice candidate offering integer-only arithmetic and 555-byte Category 1 signatures	A key recovery attack cut HAWK-256’s estimated work factor from 2^64 to 2^38; the team withdrew and NIST marked it withdrawn
SQIsign	Isogeny-based	Active	Smallest combined key and signature sizes of any candidate; signatures as low as 148 bytes	Fully constant-time signing has not yet been achieved
UOV	Multivariate	Active	96-byte signatures at Category 1, near ECDSA-class sizes; decades of cryptanalytic study	Expanded public keys exceed 200 KB; NIST is evaluating UOV mainly for specific applications rather than general-purpose use
MAYO	Multivariate	Active	Smaller public keys than standard UOV; balanced profile for general-purpose use	A 2025 wedge attack caused a 28-bit security deficiency in MAYO’s Category 1 parameter set
QR-UOV	Multivariate	Active	Resistant to the wedge attack that affected other UOV variants; public keys roughly 15 to 50 percent the size of standard UOV	Public keys remain larger than MAYO and SNOVA
SNOVA	Multivariate	Active	Potentially very small public keys and signatures, competitive with Falcon-class performance on proposed parameters	Significant cryptanalysis history; most original parameter sets have been broken, and NIST does not consider it stable

The HAWK withdrawal is worth understanding in detail because it is the clearest live example of why NIST runs multi-year, adversarial evaluation rounds instead of standardizing quickly. In late July 2026, Anthropic published cryptanalysis research showing that its Claude model had identified a previously unexploited symmetry in HAWK’s lattice structure, a nontrivial automorphism that had not been used in prior attacks. Applied to HAWK-256, the technique reduced the estimated work factor for key recovery from 2^64 down to 2^38, well below HAWK’s target security level. On July 29, 2026, the HAWK team withdrew the scheme from NIST’s standardization process, and NIST updated its round three candidate page to mark HAWK as withdrawn. The attack is exponential, not a polynomial-time break, and the researchers stated it does not extend to the other round three candidates or to lattice cryptography broadly. It does, however, confirm that a scheme can look sound through multiple review cycles and still fail under new analytic techniques, which is exactly the scenario the Additional Digital Signatures process exists to catch before standardization rather than after.

What Did Not Advance to Round Three, and Why?

Understanding who did not advance is as informative as knowing who did. The five eliminated second-round candidates reveal exactly what NIST weighted most heavily when the field was competitive: security uncertainty, performance shortfall, or consolidation in an overcrowded category.

Candidate	Family	Primary Reason for Elimination per NIST IR 8610
CROSS	Code-based (Restricted Syndrome Decoding)	Small public keys but very large signatures, similar to SLH-DSA. The underlying security problem has a much shorter study history than SLH-DSA’s, and a second-round attack forced a parameter update, combining security uncertainty with weaker performance.
LESS	Code-based (Linear Code Equivalence)	Small signatures but very large public keys, and much slower than CROSS for key generation, signing, and verification. A second-round attack raised questions about its security.
Mirath	MPCitH (MinRank, merger of MIRA and MiRitH)	Performance overlapped sufficiently with competing MPCitH candidates. NIST prioritized candidates with more established security assumptions or a superior performance profile.
PERK	MPCitH (Permuted Kernel)	FAEST offers superior speed while relying solely on AES. NIST said the decision reflected practical performance tradeoffs, not a lack of confidence in the underlying Permuted Kernel Problem.
RYDE	MPCitH (Rank Syndrome Decoding)	To avoid standardizing multiple schemes with very similar operational tradeoffs, NIST prioritized the candidates with the most robust combination of performance and community-wide analysis.

What Cryptographic Inventory Prerequisites Do Security Architects Need Before Migrating?

None of the migration steps below are safe to start without a cryptographic inventory. You cannot phase out an algorithm, plan hybrid deployment, or size a testing effort for systems you have not identified. At minimum, the inventory needs to capture, for every certificate, key, and cryptographic library in scope: the algorithm and key size in use, the protocol context (TLS, code signing, S/MIME, SSH, database encryption, firmware), the system owner, the expiration or rotation date, and whether the asset is internet-facing, internal, or embedded in a device with a long field life. A Cryptographic Bill of Materials (CBOM) is the practical artifact that captures this, and it is the same inventory a NIST IR 8547 or CNSA 2.0 compliance program will eventually require as audit evidence, so building it once for PQC migration also satisfies that later requirement.

Prioritize the inventory by exposure rather than trying to boil the ocean. Two threat models drive different urgency levels. Encrypted data is exposed to Harvest Now, Decrypt Later: an adversary records encrypted traffic today and decrypts it once a cryptographically relevant quantum computer exists, so anything with a multi-year confidentiality requirement (financial records, health data, long-lived contracts) should be inventoried and migrated first. Signatures face a related but distinct risk sometimes called Trust Now, Forge Later: an adversary cannot retroactively forge a past signature, since forgery requires real-time cryptanalytic capability at the moment of signing, but long-lived signed artifacts (firmware, legal documents, root certificates that must remain trusted for decades) are exposed to future forgery once a capable quantum computer exists. Inventory and prioritize each category separately; they do not share a timeline.

What Algorithm and Interoperability Caveats Should Security Architects Watch For?

Four caveats matter most for architects planning a production rollout, not just a lab pilot.

Signature and key size inflation breaks assumptions baked into older protocols. ML-DSA-65 signatures run roughly 3,309 bytes against ECDSA’s 64 to 72 bytes, a size increase that can overflow fixed-size fields, exceed MTU limits without fragmentation handling, or blow past packet budgets in protocols like DNSSEC that were engineered around small UDP responses. Test size-sensitive paths explicitly rather than assuming a protocol that worked with RSA or ECDSA will behave the same with ML-DSA or SLH-DSA in the payload.

Hybrid and composite certificates are the practical interoperability bridge, and they are not yet uniformly supported. Combining a classical algorithm with a post-quantum algorithm in a single certificate or key exchange, per the IETF LAMPS working group’s composite signature and hybrid key exchange drafts, lets you migrate without a hard cutover, but client, server, and middlebox support for these composite formats is uneven across TLS stacks, browsers, and legacy hardware in 2026. Validate specific client and library combinations before committing to a hybrid rollout timeline; do not assume support because a vendor’s roadmap says PQC-ready.

Round three candidates carry security assumptions that are actively being stress-tested, and that testing can eliminate a scheme mid-round, as it did with HAWK. The multivariate family (MAYO, QR-UOV, SNOVA, UOV) was hit hardest in round two by the 2025 wedge attack, which uses exterior products to expose the hidden oil subspace in characteristic-2 fields; QR-UOV was structurally immune because it uses odd-characteristic fields, while SNOVA had most of its original parameter sets broken. Updated multivariate parameter sets are due to NIST by August 14, 2026. Treat every unfinalized candidate, not just HAWK, as subject to change before you build a dependency on it.

HSM and PKI software vendor support has to be confirmed, not assumed. A finalized FIPS standard does not automatically mean your HSM firmware, PKI software, or TLS library has a validated implementation. Confirm FIPS 140-3 module validation status for ML-KEM, ML-DSA, and SLH-DSA on the specific HSM and library versions in your environment, since a NIST standard being final and a specific vendor build being validated and production-ready are two different milestones that can be months apart.

What Are the Phased Migration Steps for PQC Signature Readiness?

A production-grade migration follows six phases, in order. Skipping ahead, especially straight to production rollout, is the most common source of outages and rollback events security teams report.

1. Build and maintain a cryptographic inventory. Establish the CBOM described above and keep it current; a one-time inventory goes stale within a quarter as certificates rotate and new services deploy.
2. Prioritize by exposure and threat model. Rank inventoried assets by Harvest Now Decrypt Later or Trust Now Forge Later exposure, regulatory deadline (CNSA 2.0, NIST IR 8547), and business criticality, then sequence migration waves accordingly rather than migrating alphabetically or by convenience.
3. Pilot hybrid or composite deployments in non-production. Stand up ML-KEM and ML-DSA (or a hybrid classical plus post-quantum combination) in a staging environment that mirrors production traffic patterns and client diversity, not a synthetic test bed.
4. Validate interoperability across the full stack. Confirm behavior across PKI issuance, HSM key generation and storage, application libraries, and every client type that will connect, including older clients that may not support hybrid negotiation.
5. Roll out production migration in waves, with rollback criteria defined in advance. Migrate the highest-priority wave first, monitor for a defined observation period, and only then proceed to the next wave. Document the specific conditions (error rate threshold, handshake failure rate, performance regression) that trigger a rollback before you start, not after an incident.
6. Monitor, re-test, and maintain crypto agility as standards evolve. The HAWK withdrawal is a concrete reminder that even finalized-adjacent candidates can change status. Design certificate profiles, PKI policy, and HSM key ceremonies so that swapping a signature or KEM algorithm is a configuration change, not an architecture rebuild.

What Testing Evidence Should Security Architects Collect Before Production Rollout?

Auditors, compliance reviewers, and your own incident response team will all ask for the same underlying evidence after the fact, so collect it as you go rather than reconstructing it later. At minimum, document: an interoperability test matrix covering every client, server, and middlebox combination exercised, with pass and fail results, not just a summary; performance and latency benchmarks comparing pre- and post-migration handshake times, signing times, and verification times under realistic load, since ML-DSA and SLH-DSA have measurably different performance profiles than RSA or ECDSA; FIPS 140-3 module validation certificates or vendor attestations for every HSM and cryptographic library involved; documented pilot results, including any failures encountered and how they were resolved, before the corresponding production wave began; and rollback event logs, if any rollback occurred, showing what triggered it and how it was resolved. This evidence set is what an auditor working against CNSA 2.0 or NIST IR 8547 timelines, or a board asking for migration status, will actually ask to see. Build it once, during testing, and it becomes reusable across every future compliance cycle.

Post-Quantum Signature Implementation Checklist

• Cryptographic inventory (CBOM) covering certificates, keys, algorithms, and protocols across endpoints, applications, APIs, and infrastructure, kept current, not a one-time snapshot
• Assets prioritized by Harvest Now Decrypt Later or Trust Now Forge Later exposure and by regulatory deadline
• Confirmed FIPS 140-3 validation status for ML-KEM, ML-DSA, and SLH-DSA on the specific HSM and library versions in use
• Hybrid or composite certificate support validated against the actual client and library versions in your environment, not vendor roadmap claims
• Non-production pilot completed with documented interoperability and performance results
• Rollback criteria and thresholds defined and documented before any production wave begins
• Phased production rollout plan with defined observation periods between waves
• Monitoring in place for handshake failures, signature verification errors, and performance regressions post-migration
• Crypto-agility design in place so future algorithm changes, including any round three additional signature candidate that eventually standardizes, are configuration changes rather than architecture rebuilds
• Audit evidence package (test matrices, benchmarks, validation certificates, pilot and rollback logs) maintained and mapped to applicable compliance frameworks

Limitations

This guidance has real boundaries. Round three additional signature candidates are not finalized standards, and their status can change mid-round, as demonstrated by HAWK’s withdrawal; do not build production dependencies on any of the eight remaining candidates until NIST publishes a final standard. Sizing, performance, and security-margin figures for round three candidates are pre-standardization numbers drawn from current specifications and academic analysis; updated multivariate parameter sets are due August 14, 2026 and may change the figures cited here. CNSA 2.0 requirements for National Security Systems differ from, and are stricter than, the civilian NIST IR 8547 timeline; organizations subject to CNSA 2.0 should follow its published schedule rather than a general commercial migration plan. Finally, AI-assisted cryptanalysis, as demonstrated against HAWK in July 2026, is an emerging factor in how quickly a scheme’s security margin can be reassessed during an active evaluation window; this article reflects verified facts as of the stated update date and should be revisited as the round three timeline progresses.

What Would Encryption Consulting Recommend?

If you are working out where and how to begin your post-quantum journey, Encryption Consulting’s 9-phase PQC Advisory roadmap is built for exactly this sequencing problem. We start with a Cryptographic Discovery and Inventory, scanning your environment to identify certificates, keys, algorithms, and protocols across endpoints, applications, APIs, and infrastructure, the baseline every subsequent phase depends on.

From there, we run a PQC Assessment to evaluate quantum exposure, identify RSA- and ECC-dependent systems, and deliver a prioritized report of vulnerable assets with risk severity ratings. With that clarity, we develop a PQC Strategy and Roadmap, a phased migration plan aligned to risk appetite, regulatory requirements, and long-term crypto-agility, followed by Vendor Evaluation and Pilot Testing to select the right tools and validate interoperability before any full-scale rollout, and finally Full Implementation, deploying hybrid classical and post-quantum models across your PKI and infrastructure with monitoring for long-term cryptographic health.

Two of our products map directly onto the caveats covered above. For the HSM validation and key ceremony work referenced in the algorithm caveats section, our HSM-as-a-Service gives you FIPS 140-3 validated key protection without a hardware procurement cycle. For the hybrid and composite certificate rollout referenced in the migration steps, our CertSecure Manager platform manages certificate lifecycle across classical and post-quantum algorithms from one console, so a certificate profile change, not a re-architecture, is what it takes to move an application from ECDSA to ML-DSA or to a future round three algorithm once standardized.

CBOM Secure

Encryption Consulting’s CBOM Secure tool plays a key role in helping organizations prepare. Instead of spreadsheets, manual OpenSSL outputs, or scattered configuration files, CBOM Secure gives a clear view of crypto usage across environments: which algorithms are in use, what needs to change for post-quantum readiness, and whether systems meet security goals. It automates crypto inventories, checks TLS configurations, validates algorithms, and aligns policies, so teams move from discovery to action without guessing. Now is a good time to start: test PQC in a staging environment, map current crypto usage, and begin drafting internal migration policy. Organizations that want to pilot quantum-safe projects or shape upcoming features are welcome to reach out.

Frequently Asked Questions

What is NIST IR 8610? NIST IR 8610 is a May 2026 NIST status report on the second round of the Additional Digital Signatures standardization process, a separate track from the finalized FIPS 203, 204, and 205 standards. It documents the evaluation criteria NIST used and selects nine candidates, FAEST, MQOM, SDitH, HAWK, SQIsign, UOV, MAYO, QR-UOV, and SNOVA, to advance to round three. HAWK was subsequently withdrawn in July 2026.

Why was HAWK withdrawn from the NIST round three process? In July 2026, cryptanalysis research identified a previously unused symmetry in HAWK’s lattice structure that cut the estimated work factor for key recovery against HAWK-256 from 2^64 to 2^38. The HAWK team withdrew the scheme from NIST’s process on July 29, 2026, and NIST subsequently marked it withdrawn on its round three candidate page. NIST and the researchers stated the attack does not extend to the other round three candidates.

Should organizations wait for round three candidates before starting PQC migration? No. ML-KEM, ML-DSA, and SLH-DSA are finalized, production-ready standards, and CNSA 2.0 and NIST IR 8547 deadlines are already running. Round three additional signature candidates are years from standardization and exist to add algorithm diversity, not to replace the current migration priority. Build your inventory and start migrating now; treat round three outcomes as future crypto-agility additions.

What is the difference between NIST IR 8610 and NISTIR 8413? NISTIR 8413, published in 2022, reported on the third round of NIST’s original PQC standardization process, the competition that produced ML-KEM, ML-DSA, and SLH-DSA. NIST IR 8610, published in 2026, reports on a separate, later competition called Additional Digital Signatures, created specifically to find backup signature schemes outside the structured-lattice family that ML-DSA and FN-DSA both belong to.

Do the round three additional signature candidates affect CNSA 2.0 compliance timelines? No. CNSA 2.0 requires ML-KEM-1024 for key establishment and ML-DSA-87 for digital signatures, with National Security System timelines running from 2027 through 2030 to 2033 depending on system category. None of the round three additional signature candidates are covered by CNSA 2.0, and NSA has not indicated any plan to add them. Government contractors and defense industrial base organizations should complete CNSA 2.0 obligations on the published schedule and treat additional signature candidates as future portfolio options.

Conclusion

NIST advancing nine round three candidates, then losing one to a July 2026 cryptanalytic finding, is not a sign that the post-quantum signature problem is nearly solved. It is a sign that NIST is taking portfolio risk seriously enough to run a parallel, adversarial evaluation track for alternatives while its primary standards are still rolling out, and that the track is working as designed: HAWK failed under scrutiny before standardization, not after.

The migration priority for security architects has not changed. Move to ML-KEM, ML-DSA, and SLH-DSA now, build the cryptographic inventory that everything else depends on, and design for crypto-agility so that whichever round three candidates eventually standardize, or do not, your certificate profiles and PKI can absorb the change as configuration rather than a rebuild. The organizations that hardcoded a single scheme will feel every future algorithm change as an emergency. The ones that inventoried early and built for algorithm substitution will not.

References

• NIST, NIST IR 8610, Status Report on the Second Round of the Additional Digital Signature Schemes, May 2026
• NIST CSRC, Post-Quantum Cryptography: Additional Digital Signature Schemes
• NIST CSRC, Round 3 Additional Signatures candidate list
• NIST, NISTIR 8413, Status Report on the Third Round of the NIST PQC Standardization Process, 2022
• Federal Register, Announcing Issuance of FIPS 203, FIPS 204, and FIPS 205, August 14, 2024
• NIST, NIST IR 8547, Transition to Post-Quantum Cryptography Standards (initial public draft)
• The Hacker News, Claude AI Just Cracked a Post-Quantum Test Scheme, July 2026