Assessment reportsPublic findings
Back to Zellic site
↗
Assessment reports>Brevis>Discussion>Setup
GeneralOverview
Findings
Critical (4)
High (5)
Medium (5)
Low (12)
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

Setup

The sdk provides several helper functions for performing the setup for the circuits. In this section, we collect some observations about this.

Document that Setup should only be used for testing

The file sdk/periphery.go contains a function Setup that generates and saves an SRS that is suitable for the constraint system, using the package github.com/consensys/gnark/test/unsafekzg. We recommend to document that this Setup function (and functions that use it) are only safe for using for tests and that for production use, users should use an SRS generated by, for example, an MPC ceremony (possibly downloading such an SRS with functionality in sdk/srs/srs.go).

Dowloaded SRS not checked to be legitimate

The download function in sdk/srs/srs.go can be used (via NewSRS) to download an SRS. The downloaded file is used as is, with no validation done or check of authenticity. To protect against supply-chain attacks, we recommend to distribute a list of known hashes of SRS files with the sdk and then check downloads against this list. For users that wish to use other SRSs, documentation might be added explaining to users how to manually place their SRS into the cache directory.

No validation

SRSs are not validated to be well-formed but read with UnsafeReadFrom, which does not check that the points read are in the correct subgroup. As the data needs to be trusted anyway, given that even well-formed SRSs might be insecure if someone knows the toxic waste, this may be a reasonable trade-off, if the origin of the SRS is trusted.

No recovery on incompletely written files

SRSs are cached on disk, with the filename derived from the SRS size. Should writing an SRS file to disk be interrupted, there will be an error when attempting to read this cached SRS. This error will be caught, and instead, an SRS will be downloaded. This new SRS will, however, not be written to disk (overwriting the broken SRS), as the file already exists. Thus to be able to cache an SRS of this size again, it will be necessary to manually remove the broken file. We recommend to document this and add a printout to ReadFile in case the file is found but reading an SRS from it fails, in order to alert users to this case, as currently visible behavior does not distinguish between the file not having been present and having been present but broken in some way.

Zellic © 2025Back to top ↑