You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem
Inside our hash calculations we use go-iden3 library. And when we want to hash some blob of data we use HashBytesX from iden3 library that lead to the problem, that some hashes can be equal. hash(0x1234560000000000000000000000000000000000000000000000000000000000000000) == hash(0x123456)
Here's example how to reproduce it: at the end x1 equal x2
The reason of the problem
This happens because of iden3 sponge realisation:
// the last chunk of the message is less than 31 bytes
// zero padding it, so that 0xdeadbeaf becomes
// 0xdeadbeaf000000000000000000000000000000000000000000000000000000
And in current develop branch they removed this functionality at all.
How to resolve
To resolve this problem we need to be sure that we don't have any zero padding at the end. That means the simple way to resolve it - put bit with value 1 at the end ot sum of the bits at the end. Unfortunately such kind of changes mean that we need to change hash mechanism not only inside our cluster (inside of it it's only one line change + test fixes), but also in all tolling and wrappers that using nild. And until we don't sure what hash mechanism (Poseidon or Keccak) we want to use - better don't rush into starting making this changes.
The text was updated successfully, but these errors were encountered:
Problem
Inside our hash calculations we use go-iden3 library. And when we want to hash some blob of data we use HashBytesX from iden3 library that lead to the problem, that some hashes can be equal.
hash(0x1234560000000000000000000000000000000000000000000000000000000000000000) == hash(0x123456)
Here's example how to reproduce it: at the end x1 equal x2
The reason of the problem
This happens because of iden3 sponge realisation:
And in current develop branch they removed this functionality at all.
How to resolve
To resolve this problem we need to be sure that we don't have any zero padding at the end. That means the simple way to resolve it - put bit with value 1 at the end ot sum of the bits at the end. Unfortunately such kind of changes mean that we need to change hash mechanism not only inside our cluster (inside of it it's only one line change + test fixes), but also in all tolling and wrappers that using nild. And until we don't sure what hash mechanism (Poseidon or Keccak) we want to use - better don't rush into starting making this changes.
The text was updated successfully, but these errors were encountered: