Plonky3: The sponge construction used to get a hash function from a cryptographic permutation is not collision resistant for inputs of different lengths
Date: 2026-04
Affected: rust/p3-symmetric
Attack vector: other
Category: vulnerability-disclosure
Severity: Low
CWE: CWE-328

### Vulnerability Currently, when hashing, if the number of elements to hash is not a multiple of the rate, `hash_iter` pads by elements of the current state. This means that it is possible to create iterators of different lengths which lead to an identical hashed state. Given a simple example using a `PaddingFreeSponge` with width 8 and rate 4. Start with the zero state: [0, 0, 0, 0, 0, 0, 0, 0] Take the first 4 elements to hash and insert into the first 4 elements of the state: [h0, h1, h2, h3, 0, 0, 0, 0] Run the cryptographic permutation on the state: [p00, p10, p20, p30, p40, p50, p60, p70] Take the next 4 elements to hash and insert into the first 4 elements of the state: [h4, h5, h6, h7, p40, p50, p60, p70] Run the cryptographic permutation: [p01, p11, p21, p31, p41, p51, p61, p71] Repeat the above two steps until all elements of the iterator have been consumed. If the number of elements in the iterator is not a multiple of 4 (say there are 10 elements) then, in the final round, the first 2 elements are overwritten and so our final hash would be of: [h8, h9, p21, p31, p41, p51, p61, p71] This means that the iterators over the elements [h0, h1, h2, h3, h4, h5, h6, h7, h8, h9] and [h0, h1, h2, h3, h4, h5, h6, h7, h8, h9, p21] would lead to the same final state of the hasher. ### Impact The impact of this vulnerability is a little difficult to estimate. It is important to note that, in circumstances where the number of elements to be hashed is known and fixed in ad


Mitigations:

Architectural layers (MAESTRO):