Assessment reportsPublic findings
Back to Zellic site
↗
Assessment reports>Brevis>Low findings>Incorrect elliptic curve
GeneralOverview
Findings
Critical (4)
High (5)
Medium (5)
Low (12)Conversion from Uint248 to Uint521 fails for values wider than 96 bitsProver assignment will fail for custom inputsFunction to export Groth16 proofs only works for proofs with exactly one commitmentIncorrect constant used in twosComplementUnexpected behavior for decompose-related functions on negative inputMismatch between Uint521 type and its documentationRaw data may be overwritten by index reuseData might be arranged incorrectly by rawData[T].listInvalid receipts with empty LogField entries may be assignedParsing errors ignored in GetHexArrayIncorrect elliptic curveProof submission calls callback even if submission fails
Informational (9)
DiscussionVarious possible simplifications and optimizationsAdditional validationLack of documentation or commentsMinor recommendationsCode duplicationConsistent usage of named constantsLists and tuples' ambiguous behavior when used recursivelyBehavior of bits2Bytes and addOutput for circuit variablesIncorrect hex string and parsing errors canceling each other outReferences to MiMC instead of PoseidonUnallocated inputs slots not constrainedKeccak padding function pad10*1Confusing function GroupBySetupVerification of Poseidon constantsTest suite
Audit ResultsAssessment Results
Category: Coding Mistakes

Incorrect elliptic curve

Low Severity
Low Impact
Low Likelihood

Description

In sdk/periphery.go, the three functions ReadPkFrom, ReadVkFrom, and ReadProofFrom use the elliptic curve BLS12_377 instead of BN254 as used elsewhere.

Impact

These functions to read proving keys, verifying keys, and proofs from disk will not be compatible with the rest of the system.

Recommendations

Change BLS12_377 to BN254 in those three functions.

Remediation

This issue has been acknowledged by Brevis, and a fix was implemented in commit 9c875ce7↗.

Zellic © 2025Back to top ↑