Further hardened delta #796
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We use re-randomization to mitigate the issues described in Groth,Shoup 22 (even though our model deviates substantially from theirs). The properties of a good delta is it has to be unpredictable before the signature request is created and it has to only be used once per signing request. Since we current use H ( VRF, H(signature_request, ...) ) we guarantee the first point, but there are situations where we may try to sign again using the same delta. e.g. if our protocol crashes or someone manages to get us to ingress a duplicate message. By including the public R paramater of the presignature and since we guarantee that we don't reuse presignatures, this PR guarantees the second property required. To read more we have a deeper dive into the subject here https://docs.google.com/document/d/1-Ibv5R5mokSlcV1FhKSGmAK6jHqyRwmffe2moTzR_k4/edit.
|
We'll wait for Alessandra to come back before we merge this. |
There was a problem hiding this comment.
This is good to me because even if we retry signature generation on a failed one, a new presignature will always get used so we are able to guarantee second property.
But does changing this change any of the derived keys? Or only epsilon is the value that changes the keys?
|
Nope derived keys are only dependent on epsilon, and the hard coded signature derivation tests check that this is true. |
ChaoticTempest
approved these changes
Aug 4, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We use re-randomization to mitigate the issues described in Groth,Shoup 22 (even though our model deviates substantially from theirs).
The properties of a good delta is it has to be unpredictable before the signature request is created and it can only be used once for a signing protocol.
Since we current use
H ( VRF, H(signature_request, ...) )we guarantee the first point, but there are situations where we may try to sign again using the same delta. e.g. if our protocol crashes or someone manages to get us to ingress a duplicate message. By including the public R paramater of the presignature and since we guarantee that we don't reuse presignatures, this PR guarantees the second property required.To read more we have a deeper dive into the subject here https://docs.google.com/document/d/1-Ibv5R5mokSlcV1FhKSGmAK6jHqyRwmffe2moTzR_k4/edit.