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

Update Groth16Verifier.sol: fix snarkjs public signals check bug #333

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

andrewcoder666
Copy link

Fix snarkjs public signals check bug.
see iden3/snarkjs#518

@andrewcoder666 andrewcoder666 requested a review from a team as a code owner November 20, 2024 09:04
Copy link
Contributor

@nategraf nategraf left a comment

Choose a reason for hiding this comment

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

Can you provide more detail showing this is indeed a bug, and not a required check. If I understand correctly, the impact here of this extra check is extra gas usage. The impact of removing the check when it's required is critical soundness failure.

@andrewcoder666
Copy link
Author

Can you provide more detail showing this is indeed a bug, and not a required check. If I understand correctly, the impact here of this extra check is extra gas usage. The impact of removing the check when it's required is critical soundness failure.

hi @nategraf, according to the risc0 stark_verify.circom file, there are only 5 output signals ( public witness ) passed to the Groth16 verifier, therefore only first 5 elements should be checked before ecPairing check. The line deleted is meant to check the non-existing 6th element of the array parameter, which obviously is to access to the uninitialized memory since the array itself only contains 5 elements as shown in the code.

@Wollac
Copy link
Contributor

Wollac commented Nov 25, 2024

This makes sense to me:
uint256[5] calldata _pubSignals has only 5 elements and thus doing calldataload(add(_pubSignals, 160)) reads the calldata one element after _pubSignals[4] , which can contain undefined data

@nategraf
Copy link
Contributor

Looks like this is almost certainly correct. Thanks @andrewcoder666 for bringing this! I'm going to do a bit more due diligence before merging this.

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