Poseidon2b is secure!

Cryptography
1

There is already a topic here claiming that “Poseidon hash for Ethereum is NOT secure!”

Let me make the opposite claim.

Of course, both headlines are incomplete. A hash family cannot be called secure or insecure without fixing the field, width, capacity, round schedule, matrices, operation mode and attack model.

So let us fix all of them.

I use the following Poseidon2b instance in production:

Field:        GF(2^128)
State width:  t = 4
Rate:         r = 2
Capacity:     c = 2
Digest:       2 field elements
S-box:        x^7
Rounds:       RF = 8, RP = 58

The recent Skipping Class paper presents improved algebraic attacks against Poseidon2 and Poseidon2b.

The important part is that its main wide-state round-skipping method applies to widths t = 12, 16, 20, 24.

It does not apply to this t = 4 instance. Here the binary M4 matrix is the complete external MDS layer, not a repeated block inside the wide tensor construction.

The often repeated 2^106 improvement is also not an attack against this configuration. It belongs to the binary (n,t,c,d) = (32,24,8,8) sponge with RP = 15.

Appendix A of the paper does apply to the two-to-one feed-forward compression used by Parano1d. For the exact production parameters, its specialization gives:

d_I <= 7^73

and the paper’s quadratic work projection gives:

log2(d_I^2) = 409.873818620410...

This is not a claim of 409-bit security. It is the projection of this specific algebraic attack. It produces no attack below the intended 128-bit security level.

I made the complete correspondence executable. The audit checks the field, width, rate, digest size, rounds, matrices and compression mode against the pinned production source. Changing any of them makes the audit fail.

The calculation and source are public:

I am not claiming that no better attack can ever be found. I am claiming something checkable:

The current published algebraic attacks do not break the exact Poseidon2b instance.

If you disagree, do not give me another general argument about “Poseidon.”

Attack the exact instance.

I opened a public source-pinned research task here:

Find a cheaper attack, a valid production collision or preimage or an error in the correspondence between the paper and the implementation. Reproducible evidence will be published, attributed and reflected in the public security frontier.

2

Okay but why? If you’re using a binary tower field why bother with Poseidon and not just reach for SHA3 or BLAKE2?

3

Because I am optimizing a prove-once, verify-everywhere network not just a prover.

The reference Binius benchmark shows the tradeoff well. At roughly the same output size, Keccak-f has faster multithreaded proving and a smaller proof: 0.425 seconds and 438 KiB, versus 0.564 seconds and 507 KiB for Poseidon2b with n=128, t=4. But verification takes 46.59 ms for Keccak-f and 6.52 ms for Poseidon2b.

In my system miner produces one recursive proof for each block. It proves the block’s state transition and verifies the previous block proof. Every node checks it before accepting the block. The same verification path matters during synchronization. So verifier cost directly affects network performance and node requirements.

The exact workload matters too. The t=4 state takes two 256-bit Merkle children and returns one 256-bit digest in one permutation. PCS values and Fiat-Shamir challenges already live in GF(2^128), so recursive verification stays on the same 128-bit lanes. Keccak is still a real alternative in a binary proof system. BLAKE2 is less attractive because its ARX additions introduce carry logic.