Poseidon2 KoalaBear (width 16, alpha=3) uses only 13 partial rounds instead of required 20 — undermines Fiat-Shamir & Merkle commitments

[mhmdrizzzki]

Poseidon2 (KoalaBear, width 16, alpha=3) uses only 13 partial rounds instead of the required 20 — undermines Fiat-Shamir & Merkle commitments

Summary

Ziren's Poseidon2 KoalaBear permutation is configured with S-box degree alpha=3 but only 13 partial (internal) rounds. The Plonky3 reference (which ProjectZKM themselves fork) requires 20 partial rounds for (width=16, alpha=3) to reach the intended 128-bit security level. 13 is the correct value for alpha=7, not alpha=3. This weakens the algebraic security of every component that uses this permutation: the Fiat-Shamir challenger, the Merkle-tree commitment scheme (MMCS), and public-value hashing — the foundation of STARK/Groth16 proof soundness used by GOAT BitVM3.

Evidence

1. S-box degree is alpha=3 (cube) in all implementations

• crates/recursion/core/src/chips/poseidon2_skinny/air.rs (~L109): sbox_deg_3[i] = add_rc[i]*add_rc[i]*add_rc[i]
• crates/recursion/gnark-ffi/go/zkm/poseidon2/poseidon2_koalabear.go sboxP: i3 = i2*input (cube)
• crates/stark/src/kb31_poseidon2.rs: Perm = Poseidon2KoalaBear<16>
• ProjectZKM Plonky3 fork koala-bear/src/poseidon2.rs: KOALABEAR_S_BOX_DEGREE = 3

2. But partial rounds are hardcoded to 13 everywhere

• crates/primitives/src/lib.rs (~L1109): const ROUNDS_P: usize = 13;
• crates/core/machine/src/operations/poseidon2/mod.rs (L18): NUM_INTERNAL_ROUNDS = 13
• crates/recursion/core/src/chips/poseidon2_skinny/mod.rs (L16): NUM_INTERNAL_ROUNDS = 13
• crates/recursion/core/src/chips/poseidon2_wide/mod.rs (L22): NUM_INTERNAL_ROUNDS = 13
• crates/recursion/gnark-ffi/go/zkm/poseidon2/poseidon2_koalabear.go (L12): koalabearNumInternalRounds = 13

3. Required round count for 128-bit security (ProjectZKM Plonky3 fork, poseidon2/src/round_numbers.rs)

(16, 3) => (8, 20),   // width=16, alpha=3  -> 20 partial rounds
(16, 7) => (8, 13),   // width=16, alpha=7  -> 13 partial rounds

Ziren ships the alpha=3 permutation with the alpha=7 round count.

4. The permutation is otherwise standard — the internal diagonal matrix matches the Plonky3 fork exactly ([-2,1,2,1/2,3,4,-1/2,-3,-4,-1/2^8,-1/2^3,-127,1/2^8,1/2^3,1/2^4,127]), so there is no custom construction that would justify fewer rounds.

5. A security fix was authored, then reverted without explanation

• 8982648 (Jun 2026): fix(poseidon2): raise KoalaBear/alpha=3 partial rounds to 20
• 43185de: fix(go-runtime): koalabearNumInternalRounds = 13->20
• e0f4236: updated the failing gnark test vectors
• 0eeddf6 (Jul 2026): Revert of 8982648
• 12605c8: Revert of 43185de
• cb07d19: Revert of e0f4236
  All releases (v1.2.5, v1.2.6, v1.2.7 current) ship R_P=13.

Security impact

Poseidon2 with R_P=13 is used by:

• DuplexChallenger<Val, Perm, 16, 8> — Fiat-Shamir transform (proof soundness)
• MerkleTreeMmcs<...> — Merkle commitments (STARK oracle binding)
• PaddingFreeSponge<Perm, 16, 8, 8> / TruncatedPermutation<Perm, 2, 8, 16> — hashing public values

Under-provisioning partial rounds reduces the algebraic security below the intended 128-bit level, which can make interpolation/Gröbner-basis attacks on the Fiat-Shamir transform or commitments feasible. Recent research (GSR, "From Round Skipping to S-Box Skipping; Attacking Poseidon's Partial Layer via Subspace Restriction", IACR 2026/1692) demonstrates practical partial-round attacks on Poseidon with KoalaBear alpha=3 (CICO-1 solved at 28/31 rounds). For a proof system like Ziren, this can undermine soundness — for the GOAT BitVM3 bridge this could allow forging a proof accepted by the verifier (unauthorized withdrawal / incorrect state transition).

Suggested fix

Restore R_P=20 for the alpha=3 KoalaBear width-16 Poseidon2 in all components (Rust primitives, machine, skinny/wide chips, Go gnark runtime) and regenerate the expected test vectors. Do not revert.

Affected versions

v1.2.5, v1.2.6, v1.2.7 (current, 2026-08-14) and all tags in between.

[mhmdrizzzki]

Hi team — following up on this report with additional evidence from the git history that makes the issue stronger, and opens a question I'd appreciate your input on.

Git history shows this exact fix was already written, then reverted:

1. 8982648 (Jingping Yin, 2026-06-26) — "fix(poseidon2): raise KoalaBear/α=3 partial rounds to 20"

   • Sets NUM_INTERNAL_ROUNDS = 20 and ROUNDS_P = 20
   • Includes a regression test pinning the round count to Plonky3's poseidon2_round_numbers_128::<KoalaBear>(16, 3) → expects (R_F=8, R_P=20)
   • Commit message explicitly says: "a lower-degree S-box needs more partial rounds for algebraic-attack resistance, so under-counting silently weakens the hash"

2. 0eeddf6 (Jingping Yin, 2026-07-04) — "Revert 'fix(poseidon2): raise KoalaBear/α=3 partial rounds to 20'"

   • Reverts R_P back to 13, and deletes the security regression test that pinned the round count to the Plonky3 reference
   • Also reverted: 12605c8 (go-runtime koalabearNumInternalRounds 13→20) and cb07d19 (gnark test fix)

3. Current main (HEAD 7dc2037): crates/core/machine/src/operations/poseidon2/mod.rs still has NUM_INTERNAL_ROUNDS: usize = 13.

So as of today, the codebase ships R_P = 13 partial rounds for KoalaBear/α=3 width-16 Poseidon2, in both the STARK executor path and the recursion path (poseidon2_skinny / poseidon2_wide).

Since the fix commit itself acknowledged the Plonky3 recommendation (R_P = 20 for 128-bit security at this field/width/S-box), I'd be grateful to understand the reasoning behind the revert — e.g.:

• Was it reverted due to proof-generation performance (20 partial rounds vs 13)?
• Or a verifier/proof-compatibility constraint with existing deployed verification keys?
• Or a different security analysis concluding 13 is sufficient for the actual threat model?

I want to make sure I'm not missing context. If the revert was deliberate for performance reasons, that's a conscious security/performance tradeoff the project should document — and ideally the security pinning test should stay so the choice is explicit and auditable. If 13 rounds is genuinely considered sufficient, I'd love to see the analysis, since it contradicts the Plonky3 reference for this exact configuration.

Happy to help verify or test anything if useful. Thanks for your time!

— mhmdrizzzki

[mhmdrizzzki]

Adding the definitive reference proof — this is from the Plonky3 source itself (poseidon2/src/round_numbers.rs), not an opinion:

Reference round numbers (Plonky3 poseidon2_round_numbers_128)

For a 31-bit field (KoalaBear, p = 2^31 - 2^24 + 1) at width 16, alpha = 3:

31 => match (width, d) {
    (16, 3) => Ok((FULL_ROUNDS_128, 20)),   // <- R_P = 20 required for 128-bit security
    ...
}

Source: https://github.com/Plonky3/Plonky3/blob/main/poseidon2/src/round_numbers.rs

Ziren's current parameters

• Field: KoalaBear (31-bit) ✓
• Width: 16 ✓
• Alpha: 3 ✓
• Current R_P: 13 ← only 65% of the required 20 partial rounds

The reference explicitly computes 20 partial rounds for these exact parameters to reach 128-bit security. The 13 comes from a BabyBear/alpha=7 fork (where R_P=13 IS correct for width 16) and was never updated when the permutation was switched to KoalaBear/alpha=3.

Why this matters

The zkm-primitives poseidon2_init() and machine NUM_INTERNAL_ROUNDS both define the permutation used by the Poseidon2Permute precompile — the same permutation that hashes proofs (including deferred proof hashing via hash_deferred_proof). Running 13 instead of 20 partial rounds for a 31-bit field/alpha=3 leaves the construction below the 128-bit security target the reference proves.

The audit fix confirms it

The June 2026 Diligence-audit batch included commit 8982648:

"fix(poseidon2): raise KoalaBear/α=3 partial rounds to 20" — with a test pinning round numbers to poseidon2_round_numbers_128.

That fix was reverted (commit 0eeddf6) back to 13 and the security test was removed, with no explanation in the revert message.

Happy to help verify/restore the fix — the change itself is tiny (2 constants + test). cc @eigmax @felicityin

[mhmdrizzzki]

One more piece of evidence that clarifies what happened in the revert sequence — commit e0f4236 ("fix: the failing Poseidon2 KoalaBear gnark test", Jingping Yin, Jul 4 12:16 UTC) did not fix the implementation; it changed the test's expected output to the 13-round values so the test would pass with the weakened permutation:

 expectedOutput := [poseidon2.KOALABEAR_WIDTH]koalabear.Variable{
-   koalabear.NewF("1246627235"),   // <- 20-round outputs (correct)
-   ...
+   koalabear.NewF("1330215056"),   // <- 13-round outputs (weakened)
+   ...

So the sequence was:

1. 8982648 — fix impl to 20 rounds, update test to 20-round values ✅ (correct fix)
2. 0eeddf6 — revert impl back to 13, remove security test
3. e0f4236 — re-target the gnark test to the 13-round output so it passes
4. 12605c8, cb07d19 — revert go-runtime + gnark test changes

The tests were adjusted to match the insecure implementation rather than the implementation being corrected to the secure reference. The live permutation (machine NUM_INTERNAL_ROUNDS=13, primitives ROUNDS_P=13, gnark verifier) all use 13 partial rounds — consistent but 35% below the poseidon2_round_numbers_128 reference of 20 for KoalaBear(31-bit)/width16/α=3.

This is the complete picture; happy to discuss or help restore the fix.

[mhmdrizzzki]

Hi team — just a gentle bump on this. The evidence is all on-chain in this thread (Plonky3 reference round numbers, the git revert sequence 8982648 → cb07d194/12605c84/0eeddf6e, and the test-modified-to-match commit e0f4236).

Since this touches the Fiat-Shamir soundness of the proving system (Poseidon2 KoalaBear width-16, alpha=3 with 13 partial rounds instead of 20), we'd really appreciate a maintainer's assessment — even a quick "confirmed, will fix" or "won't fix, here's why" so the thread can move forward.

Happy to provide a minimal failing test case or a full transcript PoC if that helps triage faster. Thanks!

[mhmdrizzzki]

Confirmed in the current source (main) — the round-number issue is systemic, not isolated to one file:

All Poseidon2 layers use 13 internal rounds (should be 20)

1. crates/primitives/src/lib.rs:1107 — poseidon2_init()

const ROUNDS_F: usize = 8;
const ROUNDS_P: usize = 13;

2. crates/core/machine/src/operations/poseidon2/mod.rs:18 — prover kernel

pub const NUM_INTERNAL_ROUNDS: usize = 13;

3. crates/recursion/core/src/chips/poseidon2_skinny/mod.rs:16 — recursion chip

pub const NUM_INTERNAL_ROUNDS: usize = 13;

4. crates/recursion/core/src/chips/poseidon2_wide/mod.rs:22 — recursion chip

pub const NUM_INTERNAL_ROUNDS: usize = 13;

Reference (their own Plonky3 fork)

ProjectZKM/Plonky3 → poseidon2/src/round_numbers.rs:40:

31 => match (width, d) {
    (16, 3) => (8, 20),   // KoalaBear 31-bit, width 16, alpha=3 → 8 full + 20 partial

Upstream Plonky3/Plonky3 confirms the same: (16, 3) => Ok((FULL_ROUNDS_128, 20)).

Internal evidence: constants were prepared for 30 rounds

crates/primitives/src/lib.rs:19:

pub static ref RC_16_30: [[KoalaBear; 16]; 30] = [...]

• 30 round constants provided
• Current usage: 8 full + 13 partial = 21 rows (9 constants left unused)
• Correct usage: 8 full + 20 partial = 28 rows (2 buffer)

Why tests don't catch it

crates/stark/src/kb31_poseidon2.rs:186 (test module):

const ROUNDS_P: usize = 13;

The test reference my_perm()/inner_perm() also hardcodes 13 partial rounds — so chips are compared against an equally-wrong reference. Self-consistent tests can't catch this.

Impact

poseidon2_init() feeds:

• prover/src/types.rs — public-value commitments
• verifier/src/stark/mod.rs — verification hash
• recursion/circuit/src/hash.rs — FRI Fiat-Shamir challenges
• hash_deferred_proof — deferred proof chain

The entire proof system's hashing (commitment + Fiat-Shamir + proof chaining) uses a permutation with 7 fewer partial rounds than the 128-bit-security parameter set requires.

[eigmax]

Fixed in #532