-
Notifications
You must be signed in to change notification settings - Fork 25
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
feat!: remove default Schnorr functionality #180
feat!: remove default Schnorr functionality #180
Conversation
448833d
to
a54f332
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the changes are good, and agree that the domain should be enforced. I just have some nits about the readability in the test examples, shown below.
ACK
I disagree here. As mentioned out in #178, I feel that API ergonomics is important. Newcomers to the library are going to be confused with an API requiring Domain separation and will use a default anyway. Those looking for it will see it in the function signature and will be able to provide their own domains. |
A lot of tests have been removed -- is there a reason for the decrease in coverage? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need consensus before this can be merged.
I think implementation snafus like this are indicative of the risk of providing "a Schnorr signature". The implementer is always free to ignore the recommendation of distinct domain separation, but this API change at least forces them to make a decision. Coupled with the fact that there is no "default" signature by any common standard, I think it's an annoyance whose safety benefit outweighs the inconvenience. I understand where you're coming from, but respectfully disagree with the conclusion. Frankly, an implementer who is confused by domain separation should probably take a moment to investigate first. |
Some were specific to FFI or WASM, and naturally went away. An "invalid scalar" test didn't really make sense, and was nixed. A couple of other tests dealt specifically with the default separator, and are no longer relevant or were modified accordingly. |
One point to keep in mind is that "raw" signatures, in which the caller is responsible for challenge generation, have no inherent notion of domain separation. Currently, it's probably easiest simply to use the default separator type, since it plays no role in generating the Fiat-Shamir challenge. These are used (for good reason) in several places within the |
3f589c1
to
3c0a3dd
Compare
Removes default Schnorr signature functionality by requiring domain separation. Closes #178.
Previously, the Schnorr signature API permitted the use of a default domain separator. This introduces significant risk, as reuse of signatures across contexts can be dangerous. Further, as there are no widely-used standards for Schnorr-type signatures over the Ristretto group, there is no particularly good choice for such a domain separator.
This PR does several things:
SchnorrSignature
be provided with a domain separator via trait bound, which was previously optionalRistrettoSchnorrWithDomain
RistrettoSchnorr
toRistrettoSchnorr<H>
to require a domain separatorIt also removes all existing WASM and FFI signing and verification functionality for Schnorr signatures, since this previously used the default domain separator and there is no way to make them properly generic. Applications needing Schnorr signatures using WASM or FFI should define specific functions that use the updated types to provide a domain separator.
BREAKING CHANGE: Makes several type changes to
SchnorrSignature
,RistrettoSchnorr
, andRistrettoSchnorrWithDomain
that are breaking.