-
Notifications
You must be signed in to change notification settings - Fork 7
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
[WIP] Demo batch verification function #615
Conversation
cc @Kubuxu |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #615 +/- ##
==========================================
- Coverage 76.90% 76.46% -0.44%
==========================================
Files 64 64
Lines 5451 5477 +26
==========================================
- Hits 4192 4188 -4
- Misses 857 884 +27
- Partials 402 405 +3
|
return fmt.Errorf("unarshalling public key: %w", err) | ||
} | ||
} | ||
aggSig, err := v.blsScheme.AggregateSignatures(sigs...) |
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 don't think this is generally safe. It might be secure in this case as the message and justification are guaranteed to be unique.
No, wait, they are not. Then, yeah, this is not safe. The BatchVerify method requires that the messages be unique. There is an alternative method for BatchVerifying that introduces randomness to both the message and signature, making them linearly independent. I could write that.
It does not affect the overall scheme and is just a verification time tweak.
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.
Hmm, I guess the BatchVerify will check that messages are unique. So it might be safe.
1c1c3ad
to
fdee71b
Compare
1c17db1
to
f5af3ff
Compare
88fd68b
to
b122d56
Compare
At the moment this is only going from 4 pairings to 3, and adding some additional work into the mix for aggregation. In theory, we can go even faster but kyber currently doesn't allow for the optimizations we'd need in that case. I'm going to close this for now. It's probably easiest to simply re-implement the batch verification here, but this PR isn't going to get us any closer anyways. |
part of #614