Vulnerabilities (CVE)

Filtered by vendor Consensys Subscribe
Filtered by product Gnark-crypto
Total 3 CVE
CVE Vendors Products Updated CVSS v2 CVSS v3
CVE-2023-44273 1 Consensys 1 Gnark-crypto 2024-11-21 N/A 9.8 CRITICAL
Consensys gnark-crypto through 0.11.2 allows Signature Malleability. This occurs because deserialisation of EdDSA and ECDSA signatures does not ensure that the data is in a certain interval.
CVE-2024-45040 1 Consensys 1 Gnark-crypto 2024-09-20 N/A 5.9 MEDIUM
gnark is a fast zk-SNARK library that offers a high-level API to design circuits. Prior to version 0.11.0, commitments to private witnesses in Groth16 as implemented break the zero-knowledge property. The vulnerability affects only Groth16 proofs with commitments. Notably, PLONK proofs are not affected. The vulnerability affects the zero-knowledge property of the proofs - in case the witness (secret or internal) values are small, then the attacker may be able to enumerate all possible choices to deduce the actual value. If the possible choices for the variables to be committed is large or there are many values committed, then it would be computationally infeasible to enumerate all valid choices. It doesn't affect the completeness/soundness of the proofs. The vulnerability has been fixed in version 0.11.0. The patch to fix the issue is to add additional randomized value to the list of committed value at proving time to mask the rest of the values which were committed. As a workaround, the user can manually commit to a randomized value.
CVE-2024-45039 1 Consensys 1 Gnark-crypto 2024-09-20 N/A 6.2 MEDIUM
gnark is a fast zk-SNARK library that offers a high-level API to design circuits. Versions prior to 0.11.0 have a soundness issue - in case of multiple commitments used inside the circuit the prover is able to choose all but the last commitment. As gnark uses the commitments for optimized non-native multiplication, lookup checks etc. as random challenges, then it could impact the soundness of the whole circuit. However, using multiple commitments has been discouraged due to the additional cost to the verifier and it has not been supported in the recursive in-circuit Groth16 verifier and Solidity verifier. gnark's maintainers expect the impact of the issue be very small - only for the users who have implemented the native Groth16 verifier or are using it with multiple commitments. We do not have information of such users. The issue has been patched in version 0.11.0. As a workaround, users should follow gnark maintainers' recommendation to use only a single commitment and then derive in-circuit commitments as needed using the `std/multicommit` package.