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

Derandomize RPO-STARK DSA #358

Merged
merged 4 commits into from
Jan 8, 2025
Merged

Derandomize RPO-STARK DSA #358

merged 4 commits into from
Jan 8, 2025

Conversation

Al-Kindi-0
Copy link
Collaborator

Describe your changes

Derandomizes the RPO-STARK DSA in a similar manner to the proposal RFC6979 for ECDSA.

Once the issue of how to seed the salted Merkle tree vector commitment scheme in Winterfell is solved then this will be ready for review.

Checklist before requesting a review

  • Repo forked and branch created from next according to naming convention.
  • Commit messages and codestyle follow conventions.
  • Relevant issues are linked in the PR description.
  • Tests added for new functionality.
  • Documentation/comments updated according to changes.

@bobbinth
Copy link
Contributor

bobbinth commented Jan 5, 2025

Question not related to this PR: could the same methodology be used to make Falcon signature deterministic? Or is there something about the Flacon signatures that make it inherently impossible to do this.

@Al-Kindi-0
Copy link
Collaborator Author

Question not related to this PR: could the same methodology be used to make Falcon signature deterministic? Or is there something about the Flacon signatures that make it inherently impossible to do this.

Yes, the same principle can be applied to Falcon as well though it will require a bit of care as signature generation uses a delicate sampling procedure and we would have to derandomize it fully. The key thing that we would have to insure is that the floating point arithmetic is stable across platforms, this is in addition to the need to build the seed using the above methodology.
One more thing that we will have to guard against is hashing to the same point the message when anything about the signature generation procedure changes (e.g., bug, optimization, etc). A solution to this could be to either change the secret key whenever something about the signature procedure changes or use a versioned hash-to-map procedure.

The above is well explained here especially Section 2 and the issue of robustness across devices of the sampling procedure is analyzed in Section 3.4.2.

So the short answer is yes we can do it but we have to be more careful than the above.

Copy link

sonarqubecloud bot commented Jan 6, 2025

Copy link
Contributor

@bobbinth bobbinth left a comment

Choose a reason for hiding this comment

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

Looks good! Thank you!

@Al-Kindi-0 Al-Kindi-0 marked this pull request as ready for review January 8, 2025 19:33
@bobbinth bobbinth merged commit d2a6739 into rpo-dsa Jan 8, 2025
13 checks passed
@bobbinth bobbinth deleted the al-derandomize-rpo-dsa branch January 8, 2025 19:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants