-
Notifications
You must be signed in to change notification settings - Fork 519
batch verification: add ed25519 batch verification implementation #3031
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
batch verification: add ed25519 batch verification implementation #3031
Conversation
Codecov Report
@@ Coverage Diff @@
## master #3031 +/- ##
==========================================
+ Coverage 47.57% 47.60% +0.02%
==========================================
Files 370 370
Lines 60060 60109 +49
==========================================
+ Hits 28572 28612 +40
- Misses 28178 28186 +8
- Partials 3310 3311 +1
Continue to review full report at Codecov.
|
crypto/libsodium-fork/src/libsodium/crypto_core/ed25519/ref10/ed25519_ref10.c
Outdated
Show resolved
Hide resolved
crypto/libsodium-fork/src/libsodium/crypto_sign/ed25519/ref10/batch.c
Outdated
Show resolved
Hide resolved
crypto/libsodium-fork/src/libsodium/crypto_sign/ed25519/ref10/batch.c
Outdated
Show resolved
Hide resolved
crypto/libsodium-fork/src/libsodium/crypto_sign/ed25519/ref10/batch.c
Outdated
Show resolved
Hide resolved
crypto/libsodium-fork/src/libsodium/crypto_core/ed25519/ref10/ed25519_ref10.c
Outdated
Show resolved
Hide resolved
crypto/libsodium-fork/src/libsodium/crypto_core/ed25519/ref10/ed25519_ref10.c
Outdated
Show resolved
Hide resolved
crypto/libsodium-fork/src/libsodium/crypto_core/ed25519/ref10/ed25519_ref10.c
Outdated
Show resolved
Hide resolved
|
I tried running |
0d714f2 to
8a7a4e3
Compare
|
it looks like the batch verification interface uses unsigned long long *. |
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.
generally LGTM, with some questions & suggestions for changes
crypto/libsodium-fork/src/libsodium/crypto_sign/ed25519/ref10/batch.c
Outdated
Show resolved
Hide resolved
crypto/libsodium-fork/src/libsodium/crypto_core/ed25519/ref10/ed25519_ref10_sc.c
Outdated
Show resolved
Hide resolved
crypto/libsodium-fork/src/libsodium/crypto_sign/ed25519/ref10/open.c
Outdated
Show resolved
Hide resolved
crypto/libsodium-fork/src/libsodium/crypto_sign/ed25519/ref10/batch.c
Outdated
Show resolved
Hide resolved
crypto/libsodium-fork/src/libsodium/crypto_sign/ed25519/ref10/batch.c
Outdated
Show resolved
Hide resolved
b4c8f30 to
c1c0b76
Compare
crypto/libsodium-fork/src/libsodium/crypto_sign/ed25519/ref10/batch.c
Outdated
Show resolved
Hide resolved
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.
it looks like the batch verification interface uses unsigned long long *. @cce @tsachiherman, do you think we should change it to size_t?
It looks like they use unsigned long long for message lengths throughout most of the libsodium API (and size_t for some memory limits and some hashing APIs) so LGTM to keep mlen as unsigned long long to match the rest of the crypto_sign API.
Also, I noticed it should be const unsigned long long * to match the strict const usage in the exported API functions for input args, submitted suggested changes
crypto/libsodium-fork/src/libsodium/crypto_sign/ed25519/ref10/sign_ed25519_ref10.h
Outdated
Show resolved
Hide resolved
crypto/libsodium-fork/src/libsodium/include/sodium/crypto_sign.h
Outdated
Show resolved
Hide resolved
crypto/libsodium-fork/src/libsodium/include/sodium/crypto_sign.h
Outdated
Show resolved
Hide resolved
crypto/libsodium-fork/src/libsodium/crypto_sign/ed25519/ref10/sign_ed25519_ref10.h
Outdated
Show resolved
Hide resolved
c1c0b76 to
a70c996
Compare
…nt.iacr.org/2020/1244.pdf. we now reject non canonical R and accept signatures with a mixed group order (in order to impl a batch verification)
… and use it in the batch verification
… result to one of the small order points.
96e5029 to
a449a4b
Compare
a449a4b to
1ba1843
Compare
tsachiherman
left a comment
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 to me.
Summary The ed25519 batch verification implementation in #3031 provides a performance improvement for validating multiple signatures (such as multiple transaction signatures). Since each OneTimeSignature used by agreement votes is actually 3 ed25519 signatures, this hooks up the verifier to the batch verification implementation, yielding a ~12% performance improvement in the included benchmark on my computer. Test Plan Added benchmark, existing tests should pass.
…rand#3759) Summary The ed25519 batch verification implementation in algorand#3031 provides a performance improvement for validating multiple signatures (such as multiple transaction signatures). Since each OneTimeSignature used by agreement votes is actually 3 ed25519 signatures, this hooks up the verifier to the batch verification implementation, yielding a ~12% performance improvement in the included benchmark on my computer. Test Plan Added benchmark, existing tests should pass.
) ## Summary In this change, we plan to integrate the ed25519 batch verification algorithm. This will speed up the process of verifying the digital signature of several transactions by roughly 2.4X. This PR implements the algorithm according to the following paper: https://eprint.iacr.org/2020/1244.pdf This PR fixes a **bug** in the paper (Listing 1.2) that didn't reject the points (-0,-1) and (-0,1) Another blog article with similar background: https://hdevalence.ca/blog/2020-10-04-its-25519am **Changes Overview** Changes made on the single ed255519 verification : 1. Signatures that contain small order group R value will now be accepted. 2. use the cofactor version of the equation to validate the signature. (multiple the result by the cofactor and compare to natural element) 3. add ge25519_is_canonical_vartime function (check if a given y point has a canonical or non-canonical encoding ): - optimize this function using the the quick check. - reject two non-canonical points by comparison (points (-0,-1) and (-0,1), this resolves a bug in the paper). Add the batch verification implementation from https://github.com/floodyberry/ed25519-donna to our fork of libsodium. Changes made on the batch verification (to match the single verification): 1. reject small order A (PK) 2. reject non-canonical A (PK) 3. reject non-canonical R 4. reject non-canonical S 5. use the cofactor equation ## Test Plan The following tests were added to the libsodium's test suite. 1. Test against the White Paper's test vector 2. Test against all non-canonical options for R 3. Test against all non-canonical options for S
…rand#3759) Summary The ed25519 batch verification implementation in algorand#3031 provides a performance improvement for validating multiple signatures (such as multiple transaction signatures). Since each OneTimeSignature used by agreement votes is actually 3 ed25519 signatures, this hooks up the verifier to the batch verification implementation, yielding a ~12% performance improvement in the included benchmark on my computer. Test Plan Added benchmark, existing tests should pass.
This adds a pure-Go ed25519 BatchVerifier implementation based on the ed25519consensus library, with additional checks to preserve our ed25519 validation criteria, last updated in #3031. Like our libsodium batch verification implementation, the IsCanonicalY check here is also based on the "Taming the Many EdDSAs" paper in https://eprint.iacr.org/2020/1244 New tests added to compare ed25519 criteria results match our existing libsodium- and ed25519-donna-based batch verification implementation (from #3031 and defined in algorandfoundation/specs#60). New test helpers run test vectors with different batch sizes, taken from - 12 edge cases from "Taming the many EdDSAs" Appendix C, Table 6c, also used in our libsodium fork's tests in batch verification: add ed25519 batch verification implementation #3031 - 1025 successful cases from our libsodium fork's tests, also added in batch verification: add ed25519 batch verification implementation #3031. - 196 edge cases used to draw the 14x14 grid visualizations from the blog post "It's 255:19AM. Do you know what your validation criteria are?" and used in ed25519consensus - 768 edge cases from the Go crypto package's crypto/ed25519/ed25519vectors_test.go
This adds a pure-Go ed25519 BatchVerifier implementation based on the ed25519consensus library, with additional checks to preserve our ed25519 validation criteria, last updated in algorand#3031. Like our libsodium batch verification implementation, the IsCanonicalY check here is also based on the "Taming the Many EdDSAs" paper in https://eprint.iacr.org/2020/1244 New tests added to compare ed25519 criteria results match our existing libsodium- and ed25519-donna-based batch verification implementation (from algorand#3031 and defined in algorandfoundation/specs#60). New test helpers run test vectors with different batch sizes, taken from - 12 edge cases from "Taming the many EdDSAs" Appendix C, Table 6c, also used in our libsodium fork's tests in batch verification: add ed25519 batch verification implementation algorand#3031 - 1025 successful cases from our libsodium fork's tests, also added in batch verification: add ed25519 batch verification implementation algorand#3031. - 196 edge cases used to draw the 14x14 grid visualizations from the blog post "It's 255:19AM. Do you know what your validation criteria are?" and used in ed25519consensus - 768 edge cases from the Go crypto package's crypto/ed25519/ed25519vectors_test.go
Summary
In this change, we plan to integrate the ed25519 batch verification algorithm. This will speed up the process of verifying the digital signature of several transactions by roughly 2.4X.
This PR implements the algorithm according to the following paper:
https://eprint.iacr.org/2020/1244.pdf
This PR fixes a bug in the paper (Listing 1.2) that didn't reject the points (-0,-1) and (-0,1)
Another blog article with similar background: https://hdevalence.ca/blog/2020-10-04-its-25519am
Changes Overview
Changes made on the single ed255519 verification :
Add the batch verification implementation from https://github.com/floodyberry/ed25519-donna to our fork of libsodium.
Changes made on the batch verification (to match the single verification):
Test Plan
The following tests were added to the libsodium's test suite.