Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Poseidon same hash from different bytes blob data #82

Open
knazarov opened this issue Jan 31, 2025 · 0 comments
Open

Poseidon same hash from different bytes blob data #82

knazarov opened this issue Jan 31, 2025 · 0 comments
Assignees

Comments

@knazarov
Copy link
Collaborator

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

	userPrivateKey, err := crypto.GenerateKey()
	s.Require().NoError(err)
	userPublicKey := crypto.CompressPubkey(&userPrivateKey.PublicKey)

	value := types.NewValueFromUint64(123_456_789)
	walletCode := contracts.PrepareDefaultWalletForOwnerCode(userPublicKey)

	codeTmp1 := types.BuildDeployPayload(walletCode)
	x1 := types.CreateAddress(types.FaucetAddress.ShardId(), codeTmp1)
	
	codeTmp2 := types.BuildDeployPayload(walletCode, common.EmptyHash)
	x2 := types.CreateAddress(types.FaucetAddress.ShardId(), codeTmp2)
	
        s.Require().NotEqual(codeTmp1, codeTmp2)
	s.Require().Equal(x1, 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.

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

No branches or pull requests

3 participants