China’s Next-Generation Crypto Candidates Drew 104 Public Findings in Three Days. Researchers Broke Five Designs on Day Two

23 September 2026 – China’s Institute of Commercial Cryptography Standards (ICCS) published the first-round candidates of its Next-generation Commercial Cryptographic Algorithms Program (NGCC) on September 20. The public-key list names 34 digital signature schemes, 41 key encapsulation mechanisms (KEMs) and nine key-exchange protocols, and a separate list names 35 hash functions.

By 07:33 UTC on September 23, ngcc.dev, a site run by Finnish cryptographer Markku-Juhani O. Saarinen, listed 104 findings against 65 of the 119 candidates. Saarinen’s AI-assisted sweep on September 21 produced 53 findings, mostly bugs in the submitted code. On September 22, other researchers added 38 findings, 27 of them in the designs, including practical breaks of the Tins and Facto-DSA signature schemes and the MoFang and Neulaser hash functions.

None of the 119 candidates is standardized or deployed, so no production system is affected. In the first three days of public review, researchers found practical breaks in five of the designs entered in China’s post-quantum competition, and Chinese research groups posted some of those attacks on ICCS’s own public forums.

Saarinen credits AI assistance on each of the 64 findings he has written. In July, the HAWK team withdrew its signature scheme from NIST’s standardization process after an AI-assisted attack by Anthropic.

The NGCC Program and Its Round 1 Rules

ICCS launched NGCC on February 5, 2025 in response to the threat of quantum computing, under the arrangement of China’s Cryptography Standardization Technical Committee. The institute was set up at the end of 2024 as a public institution that also operates as the Commercial Cryptography Testing and Certification Center. ICCS said it would consider NGCC’s finalists for standardization.

ICCS issued formal calls for public-key and hash proposals on October 9, 2025, with a submission deadline of June 30, 2026. A third track, for block ciphers, runs on a separate schedule.

The resulting standards will govern commercial cryptography, the category Chinese law assigns to information that is not a state secret. In practice, that covers the cryptography used by banks, telecom operators and other companies in China.

The submission requirements for public-key algorithms set three mandatory classical security strengths of 128, 256 and 512 bits, with quantum-resistant strengths of at least 80, 128 and 256 bits. A 384-bit classical level is optional. ICCS defines n-bit strength as a best known attack costing at least $$2^n$$ operations.

ICCS excludes algorithms that are in, or have completed, standardization by international bodies, countries or regions, along with variants that differ only slightly. That rules out ML-KEM, ML-DSA and the other NIST standards.

Submitters had to provide English-language specifications, a reference implementation in ISO C written against an ICCS programming interface, an optimized implementation and known-answer test vectors. ICCS supplied placeholder hash and extendable-output functions, built on China’s SM3 hash standard, for checking correctness and preliminary performance only, and said later rounds would replace them with functions based on new hash algorithms. Later rounds will also require results from hardware implementations.

ICCS published every candidate’s submission package for download. It runs an NGCC Forum with public mailing-list discussions of the public-key candidates and a separate forum for the hash candidates. Its submission rules describe public review as an important reference for the evaluation.

Three Days of Reports on ngcc.dev

Saarinen is Professor of Practice at Tampere University, co-authored Round5, a KEM that reached the second round of NIST’s post-quantum process, and chairs the cryptography special interest group at RISC-V International, according to his homepage. According to the site’s public commit history, the first batch of reports was published on the morning of September 21, Finnish time. The site states that it is not affiliated with NICCS, the ICCS website.

Each report names the candidate, the affected parameter sets, a classification, a status and the credited researcher. For each reported candidate, Saarinen compiles the reference code from the submitters’ own sources and drives it through the official ICCS interface, the same way the official test-vector generators do, and publishes the commands that reproduce runtime findings in a public GitHub repository.

Counts from the ngcc.dev report pages, build of 07:33 UTC on September 23, 2026.

Of the 104 findings, the site classifies 61 as implementation and 43 as design. It marks 97 as Confirmed, three as Leads, two as Probable and two as proof gaps. It rates 41 findings critical, 24 high, 26 medium and 13 low. On September 23, the site raised 13 findings from high to critical, all of them about parameter sets that deliver 256 bits of security where 512 bits are claimed. It also lowered one DOVE finding from critical to medium.

Saarinen is credited “with AI assistance” on all 64 of his findings. Mikhail Kudinov is credited on eight findings against the FlexTree signature scheme, and Kwiatkowski on four, including a universal forgery against the CS signature scheme that he submitted as a pull request. The other contributors include Tsinghua Hash Lab (six findings) and Cryptanalysts001 at the Institute of Software, Chinese Academy of Sciences (six).

Twenty-three findings name one of ICCS’s two forums as their original source: 13 from the hash forum and 10 from the public-key forum. On September 22, the IACR ePrint archive also published a paper on seven submitted hash functions that reports explicit collisions for MoFang and Neulaser.

Day One: Bugs in the Submitted Code

Twenty-six of the 31 critical findings dated September 21 concern implementations. According to the reports, they include the following.

• UVW. The signature scheme’s reference API wrapper computes the verification result, then returns success regardless, so it accepts any signature.
• Polar-KEM. The implementation derives its decoding transform from a seed inside the public key, and functions shipped with the submission recover the session key from a public key and a ciphertext. A participant on the public-key forum confirmed the break independently. The report states that the specified construction, which keeps the transform secret, is not attacked.
• HEP-QC, VDOO and Galas. Key generation in this KEM and two signature schemes ignores the random generator supplied through the ICCS interface and starts from an all-zero state, so every fresh process produces the same key pair.
• Aigis-Enc+, CheetahKEM and LoongKEM. Faulty implicit rejection returns the real shared secret, or most of its bits, for modified ciphertexts, which breaks IND-CCA security. In Aigis-Enc+, 5,632 of 7,168 single-bit ciphertext changes returned the original secret.
• CreTAKE. In six instances of this key-exchange protocol, a bits-versus-bytes error leaves 64 random bits as the only secret input to the session key, which a passive eavesdropper can recover with $$2^{64}$$ offline work. The error appears in 23 source files and in every submitted test vector.
• CEDRUS+C. A parsing error in this hash-based signature scheme discards the hypertree index, and an end-to-end attack forged a signature from 1,000 chosen-message signatures in about three CPU-minutes.
• SQIsign2D2. In one variant’s default release build, the isogeny-based verifier’s decision depends on stack memory left by a previous call, and it can accept an all-zero signature.
• Eijen and MasterCube. Padding errors in these hash functions produce collisions between messages of different bit lengths. In Eijen, seven zero bits hash to the same value as the empty string.

The five critical design findings from that day are all shortfalls against the 512-bit level, discussed below.

Day Two: Breaks in the Designs

Tianyuan Xie reported on the public-key forum that a single Tins signature reveals the complete signing witness. The attack needs binary Gaussian elimination on at most 1,044 unknowns and applies to all three parameter sets. The recovered witness signs arbitrary messages.

A researcher posting as MingLLuo, who disclosed AI assistance, showed in a GitHub issue that the Facto-DSA-128 public key yields an equivalent signing trapdoor. In the submitted experiments, recovery of the trapdoor takes seconds. With it, signing takes under a second per message.

Tsinghua Hash Lab reported on the hash forum that MoFang’s round keys cancel under a chosen message difference, which gives deterministic full-round collisions for all six MoFang instances. Tsinghua Hash Lab and Cryptanalysts001 each reported a different way to merge two Neulaser states after one round, which gives collisions for all three variants.

Kudinov’s FlexTree findings include a specified verifier that omits two encoding checks, which permits forgeries at about $$2^{40.4}$$ operations for FlexTree-160s against implementations that follow the specification. The submitted verifier performs both checks.

Jinnuo Li reported on the public-key forum that Amoeba’s re-encryption check compares only every fourth ciphertext byte. The ngcc.dev reproducer recovered the full Amoeba-576 key in 128,161 decapsulation queries, against the reporter’s figure of about 30,000.

Two design results date from September 21. Kwiatkowski showed that the CS verifier reads the challenge only modulo 2, and the sign-07 report puts the resulting CS-128 forgery at about $$2^{108.08}$$ hash evaluations classically, or $$2^{54}$$ with Grover’s algorithm, below the required 128 and 80 bits. In Saarinen’s test of TRIKE, the decoder as written in the specification recovered none of 1,000 honest shared secrets. The submitted code uses a different decoder, which recovered all 1,000.

My Analysis

When I sort the 104 findings by what an attacker would need, three groups appear. Most are programming errors in submitted reference code, found by Saarinen’s AI-assisted sweep on the first day. Sixteen are shortfalls against a 512-bit security target that no attacker could exploit. Six are practical breaks of five designs, and all six were posted on September 22.

Most Day-One Findings Were Bugs in Submitted Code

Forty-one of the 54 findings dated September 21 are implementation issues, and 68 of all 104 are rated trivial to discover. UVW’s verifier, the key generation in HEP-QC, VDOO and Galas, and the rejection masks in three KEMs all fail the negative tests a developer would write before attempting any cryptanalysis: verify a corrupted signature, generate two keys from different seeds, flip one ciphertext bit. In fairness to UVW, its verifier does accept every valid signature.

Known-answer tests missed all of these defects. They compare the outputs for valid inputs against stored values, and each of these implementations reproduces its own stored values correctly. CreTAKE’s 64-bit error is present in every test vector the team submitted, so a correct independent implementation will reproduce none of them. In TRIKE, the error is in the specification, and the test files match the submitted code.

Polar-KEM is one of the 65 candidates with reports, and its break is confined to the submitted code. Its implementation made the secret transform public, which gives every observer the session key, and the report itself says the specified construction was not attacked. Fixing the random-number wiring would likewise restore the intended key generation in HEP-QC, VDOO and Galas without touching the underlying hard problem.

Saarinen’s September 23 batch continued the pattern. Most of the 11 new findings are robustness defects, such as hash functions that return a successful all-zero digest when memory allocation fails and KEM decapsulators that crash on malformed ciphertexts.

Five Designs Failed on Day Two

The second day produced the results that matter for the competition. Tins leaks its signing witness in one signature, Facto-DSA-128 gives away an equivalent trapdoor from its public key in seconds, and MoFang and Neulaser produce collisions at full rounds. FlexTree’s specified verifier accepts forgeries at about $$2^{40}$$ work, roughly a trillion operations, for anyone who implements the specification rather than copying the submitters’ code. I would not expect any of these five schemes to advance to a second round in the form submitted. I would expect the same for CS unless its designers change parameters.

Four of those six findings came from ICCS’s own forums, posted by Tsinghua Hash Lab, Cryptanalysts001 at the Chinese Academy of Sciences and Tianyuan Xie. The hash results also appeared as a paper on ePrint within two days of the candidate list. The division of labour over the three days is clear in the data. The AI-assisted sweep produced breadth, 64 findings across 48 candidates, mostly in code. The deeper attacks on designs came from cryptanalysts working on individual schemes, and one of them, MingLLuo, also disclosed AI assistance.

Sixteen Findings Concern the 512-Bit Security Level

ICCS asks for more security than any other post-quantum competition I know of. Its top mandatory level, 512 bits of classical strength, is double the 256 bits of an exhaustive AES-256 key search, and it comes with a 256-bit requirement against quantum attackers.

Sixteen findings put the cost of an attack at about $$2^{256}$$ operations in parameter sets claiming 384 or 512 bits. Some come from 512-bit message digests, which cap collision-based forgery at $$2^{256}$$, as in BiT-512, TSUOV and Origami. Others come from keys derived from at most 256 bits of seed material, as in COMPASS-KEM, CTL, HEP-QC, MAMBA-Viper and NTRE.

No computer anyone can build will perform $$2^{256}$$ operations, so none of these 16 findings threatens data. Under ICCS’s rules they still fail the claim, because a parameter set sold as 512-bit that delivers 256 bits does not meet the requirement, and each fix costs size or speed. Since September 23, the site rates all 16 as critical, the same label it gives Tins and Amoeba. I would read the severity column on ngcc.dev as a measure of distance from the submitter’s claim, and sort by attack cost before drawing any conclusion from it.

The 512-bit public-key level also depends on the hash track. FlexTree’s 384- and 512-bit sets extend SM3 in counter mode. SM3 has a 256-bit internal state, and counter mode cannot raise security above 256 bits. The FlexTree authors acknowledge on page 45 of their specification that these sets may not reach their named levels. ICCS’s own placeholder XOF uses the same counter-mode construction over SM3, so any candidate that relies on it at the 384- and 512-bit levels inherits the same ceiling until ICCS replaces it. Public-key candidates that claim 512 bits will need a replacement hash with a wider internal state, and the program’s own hash track is the obvious source. Researchers broke two of its candidates, MoFang and Neulaser, on the second day.

YuanYang.DSA and the 2006 NTRUSign Attack

YuanYang.DSA’s implementation error repeats a leak that Phong Nguyen and Oded Regev exploited in 2006, when they recovered NTRUSign secret keys from signature transcripts in the version of that scheme without perturbations. Modern hash-and-sign designs add a random perturbation with a precisely shaped distribution so that signatures reveal nothing about the secret basis.

YuanYang.DSA’s implementation shapes that perturbation with the wrong matrix, and Kwiatkowski measured the resulting leak in 4,000 signatures from one key. The faulty code is identical in all three parameter sets. He has not demonstrated key recovery, and the report says so.

First-Round Attrition at NIST, CACR and KpqC

Every first round I have followed lost a large share of its candidates. NIST accepted 69 first-round candidates in December 2017 and advanced 26 in January 2019, according to its first-round status report. China’s own 2018–2019 national algorithm design competition, run by the Chinese Association for Cryptologic Research, admitted 38 public-key algorithms to its first round and advanced 14, according to the State Cryptography Administration. South Korea’s KpqC competition selected four algorithms in January 2025, after several candidates were attacked mid-competition and then repaired or dropped.

What NGCC compressed is the timescale. NIST’s first-round attacks arrived over months. NGCC’s arrived in three days, with reproduction commands attached.

Saarinen’s Method, From BRUTUS in 2014 to AI Assistance in 2026

Saarinen has run this kind of sweep before. In 2014 he released BRUTUS, an automated framework for finding cryptanalytic weaknesses in the first-round candidates of the CAESAR authenticated-encryption competition.

At the WAC 8 workshop in August, Saarinen said he uses command-line coding agents such as Claude Code and Codex in a sandbox with SageMath and other tools, and has models from different vendors cross-check each other. In July he used that setup to test a claimed polynomial-time attack on HAWK and showed that one of its heuristics fails, three weeks before Anthropic published the Claude Mythos Preview result that led the HAWK team to withdraw.

His closing slide at WAC 8 read, “AI can’t find bugs that aren’t there.” Anthropic said that validating its AI-found AES result took two researchers nearly a month. With Saarinen’s published commands, anyone can rebuild a candidate and rerun a runtime finding. Submitters to any competition should now assume that a defect in published code will be found within a day, and should run negative tests and fuzzers before they submit.

ICCS Ran Round 1 in the Open

In my 2025 standardization update, I expected China’s process to be less transparent than NIST’s, possibly without all submissions or analyses published in English. I was wrong. ICCS published every package and required English specifications. It also supplied a common programming interface and runs public forums for both tracks, and Chinese university and academy groups are using them to publish attacks on submissions.

When NGCC launched in February 2025, a participant on NIST’s pqc-forum asked whether ICCS would run public mailing lists like NIST’s. It does, and China’s State Cryptography Administration has also opened research projects on the candidates, including side-channel evaluation of their hardware implementations, in its January 2026 announcement.

In June, I wrote that the ICCS call invites worldwide attack papers along with submissions from any country. The first ones arrived within a day, and Saarinen could produce them that fast because ICCS published complete packages with a common interface.

Because ICCS excludes standardized algorithms, NGCC’s winners will differ from the NIST algorithms whatever the evaluation finds. China has long used its own SM-series algorithms in place of RSA and AES, and NGCC takes the same approach to post-quantum cryptography, as part of the broader push for cryptographic sovereignty I wrote about last year. Dustin Moody, who leads NIST’s post-quantum project, told New Scientist in February 2025 that NIST would monitor the Chinese effort and would not rule out adopting a strong algorithm from it.

What Changes for Organizations With Operations in China

Nothing in these reports affects ML-KEM or ML-DSA deployments. Banks, telecom operators and manufacturers with Chinese operations should follow NGCC, because it will produce the post-quantum algorithms that Chinese commercial systems are expected to adopt, and those will not be the NIST algorithms.

Wang Xiaoyun of Tsinghua University told Reuters in March that China will likely have national post-quantum standards within three years, and named finance and energy as the priority sectors for migration. That is her estimate, not an ICCS schedule. With 119 candidates in Round 1 and hardware results required in later rounds, I’d treat 2029 as the earliest plausible date for NGCC standards and plan for later ones.

Systems that will run in China need to support an additional algorithm family alongside ML-KEM and ML-DSA. Crypto-agility, the ability to add or replace algorithms without re-engineering applications, is the preparation for that. No product should implement a Round 1 candidate for anything beyond testing, and this week’s reports cover 65 of them. My recent piece on diverging national migration requirements maps the other jurisdictions a multinational has to reconcile, and my CNSA 2.0 comparison covers where China’s requirements differ from the American ones.

ICCS published 119 candidates on September 20. By the morning of September 23, 65 of them had public reports, and five designs had practical breaks. Next, I will watch the NGCC forums for the teams’ responses, and ICCS’s first-round evaluation for citations of the public analysis that its own rules call an important reference.