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.

4

That doesn’t say much about Keccak-f, SHA-256, or any other hashes they tried. Binius is merely the polynomial commitment scheme, there’s a whole lot more machinery sitting on top of it – namely the arithmetization scheme. Assuming the quality of their circuit implementations is equally high, have you considered the possibility that their arithmetization is crap? Or that it’s tailored towards optimizing Poseidon specifically? Do you otherwise have a plausible explanation for such a difference?

I also do not quite understand their benchmark summary table: what the heck do n=32 and t=16 mean for SHA-256? SHA-256 hashes in 256-bit blocks, period. It doesn’t have a sponge construction, there’s no “t”.

5

In that table, n=32, t=16 describes sixteen 32-bit words or one 512-bit SHA-256 message block. It is not a sponge parameter. The heading is overloaded. The benchmark script does not even pass n or t to the SHA-256 circuit.

And yes, this is an implementation benchmark. I never claimed it proves that Poseidon2b is universally faster than every possible SHA or Keccak circuit. It measures complete circuits in one Binius stack. The arithmetization is part of the cost I care about. Poseidon2b being designed for efficient binary-field arithmetization is the point, not a hidden bias. Could their SHA or Keccak circuit be improved? Yep. The table does not separate intrinsic cost from implementation quality. But “maybe their arithmetization is crap” is not a result. Show a better circuit under the same workload and I will benchmark it. Until then, repeating that one might exist tells us nothing.

Edit: Your own PCS README offers SHA-256 “for fast verification on the EVM” and Poseidon2 “for efficient recursion.” So you already know why arithmetization matters here. Yet you claimed SHA-256 uses 256-bit blocks. It uses 512-bit blocks.