Skip to content

Conversation

@Tabaie
Copy link
Contributor

@Tabaie Tabaie commented Oct 21, 2025

For use as a compression function and not a range-extended hasher


Note

Expose NewDefaultPermutation across Poseidon2 packages and switch Merkle–Damgård hashers to use it; add SetBytesCanonical property tests and koalabear Poseidon2 test vectors.

  • Poseidon2:
    • Add NewDefaultPermutation() returning Permutation{GetDefaultParameters()} in poseidon2.go for multiple curves/fields and update NewMerkleDamgardHasher() to use it.
    • Adjust hasher buffer sizing to derive from permutation params; update generator templates accordingly.
  • Tests:
    • Add property-based test: SetBytesCanonical(Bytes()) remains constant in fp/fr element tests across curves and in field generator templates.
    • Add koalabear Poseidon2 test vectors (poseidon2/test-vectors.json) and vectors_test.go validating width, block sizes, and output.

Written by Cursor Bugbot for commit 413eea9. This will update automatically on new commits. Configure here.

@Tabaie Tabaie marked this pull request as ready for review October 22, 2025 14:12
@Tabaie Tabaie requested a review from ThomasPiellard October 22, 2025 14:12
@Tabaie Tabaie requested a review from YaoJGalteland October 27, 2025 21:10
"out": [0, 0, 0, 0, 0, 0, 0, 0]
},
{
"in": [[0, 1, 2, 3, 4, 5, 6, 7]],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The discrepancy seems to arise from differences in how the uint32 values are being encoded into field.Element objects and then serialized into byte buffers.

  • When using this encoding:
    _, err = binary.Encode(buf[i*koalabear.Bytes:(i+1)*koalabear.Bytes], binary.BigEndian, in[i])
    I printed the input to Permutation (the place right before h.Permutation in (h *Permutation) Compress), which is:
    [[0] [0] [0] [0] [0] [0] [0] [0] [0] [33554430] [67108860] [100663290] [134217720] [167772150] [201326580] [234881010]], it is equal to [[0] [0] [0] [0] [0] [0] [0] [0] [0] 1xOne(), 2xOne(), 3xOne(),...].

  • When using this encoding:

elem := koalabear.Element{in[i]}
elemBytes := elem.Bytes()
copy(buf[i*koalabear.Bytes:(i+1)*koalabear.Bytes], elemBytes[:])

the input to permutation is: [[0] [0] [0] [0] [0] [0] [0] [0] [0] [1] [2] [3] [4] [5] [6] [7]].

I think the input transformation depends on how you interpret and encode the uint32 values into the field.Element representation.

Copy link
Contributor

@YaoJGalteland YaoJGalteland Oct 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

_, err = binary.Encode(buf[i*koalabear.Bytes:(i+1)*koalabear.Bytes], binary.BigEndian, in[i])
and

elem := koalabear.NewElement(uint64(in[i]))
elemBytes := elem.Bytes()
copy(buf[i*koalabear.Bytes:(i+1)*koalabear.Bytes], elemBytes[:])

produce equivalent results. So the main difference from the first line is how in[i] is converted to a koalabear.Element.

cursor[bot]

This comment was marked as outdated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants