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

Added fuzzer tests #500

Merged
merged 20 commits into from
May 10, 2024
Merged

Added fuzzer tests #500

merged 20 commits into from
May 10, 2024

Conversation

matteosz
Copy link
Contributor

@matteosz matteosz commented Mar 4, 2024

This PR adds some fuzzers to sign/tbls and sign/bls. It also reimplements the bls tests which were commented out in the drandmerge fork

@matteosz matteosz self-assigned this Mar 4, 2024
@matteosz matteosz marked this pull request as ready for review March 10, 2024 15:28
sign/cosi/cosi_test.go Outdated Show resolved Hide resolved
Comment on lines 29 to 35
suite := bn256.NewSuite()
n := 10
t := n/2 + 1
th := n/2 + 1

secret := suite.G1().Scalar().Pick(suite.RandomStream())
priPoly := share.NewPriPoly(suite.G2(), t, secret, suite.RandomStream())
priPoly := share.NewPriPoly(suite.G2(), th, secret, suite.RandomStream())
pubPoly := priPoly.Commit(suite.G2().Point().Base())
sigShares := make([][]byte, 0)
Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if this setup phase really needs to be repeated when fuzzing or whether fuzzing should occur on the message only, WDYT?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was thinking that fuzzing on the parameter n would have been more interesting than using just; I'd say that the cost of repeating these operations is not that expensive and leads some value in increased exploration. But if you feel it's relevant to fuzz only on n I can change it

Copy link
Contributor

Choose a reason for hiding this comment

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

In general, fuzzing should be repeatable. Given the same "fuzzing corpus of input messages" I should get the same outputs/results in all runs.

Could we change this code so that there is no randomness outside of the fuzzer msg?
Maybe seed the RandomStream using msg.

sign/cosi/cosi_test.go Outdated Show resolved Hide resolved
Add a more prominent disclaimer about target audience of this library.
sign/tbls/tbls_test.go Outdated Show resolved Hide resolved
Copy link

sonarcloud bot commented Mar 23, 2024

Please retry analysis of this Pull-Request directly on SonarCloud

sign/tbls/tbls_test.go Outdated Show resolved Hide resolved
Copy link
Contributor

@AnomalRoil AnomalRoil left a comment

Choose a reason for hiding this comment

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

LGTM. Should we wait on the big merge first?

Copy link
Contributor

@pierluca pierluca left a comment

Choose a reason for hiding this comment

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

LGTM

@matteosz matteosz changed the base branch from master to drandmerge May 4, 2024 12:52
Copy link

sonarcloud bot commented May 4, 2024

Quality Gate Passed Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
6.6% Duplication on New Code

See analysis details on SonarCloud

@AnomalRoil AnomalRoil merged commit 848f428 into drandmerge May 10, 2024
7 of 8 checks passed
@AnomalRoil AnomalRoil deleted the matteo-fuzz-testing1 branch May 10, 2024 08:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants