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
In the std/multicommit we allow to collect all variables we want to commit to and only use single api.Commit for making the verifier more efficient (every call to api.Commit creates a new pairing computation for Groth16 and adds scalar multiplication in PLONK). The approach for now for computing the per-instance commitment is to derive the individual commitments using squaring from the root commit. However, in some cases with small 2-adicity we may obtain 1 as a individual commitment (and which will stay 1), allowing a malicious prover to break the soundness of the circuit (as the challenge is known ahead of time).
Currently it doesn't have an impact as requires at least 192 commitments with curves we don't use, but it would be better to have a sound implementation.
Possible Fix
Use consecutive powers instead of squaring or use the same root commitment. I prefer using consecutive powers as when using same root commitment imo we need to be aware not to use in contexts where we expect the commitments to be different. Even better approach would imo to use hashing, but it may have negative impact on the constraint count when we use many commitments. But we could measure, maybe it isn't too bad.
The text was updated successfully, but these errors were encountered:
Description
In the
std/multicommit
we allow to collect all variables we want to commit to and only use singleapi.Commit
for making the verifier more efficient (every call toapi.Commit
creates a new pairing computation for Groth16 and adds scalar multiplication in PLONK). The approach for now for computing the per-instance commitment is to derive the individual commitments using squaring from the root commit. However, in some cases with small 2-adicity we may obtain1
as a individual commitment (and which will stay 1), allowing a malicious prover to break the soundness of the circuit (as the challenge is known ahead of time).Currently it doesn't have an impact as requires at least 192 commitments with curves we don't use, but it would be better to have a sound implementation.
Possible Fix
Use consecutive powers instead of squaring or use the same root commitment. I prefer using consecutive powers as when using same root commitment imo we need to be aware not to use in contexts where we expect the commitments to be different. Even better approach would imo to use hashing, but it may have negative impact on the constraint count when we use many commitments. But we could measure, maybe it isn't too bad.
The text was updated successfully, but these errors were encountered: