-
Notifications
You must be signed in to change notification settings - Fork 311
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
Turbocharge by using Jacobi representation, 2-ary NAF and precomputation #127
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
cce7792
to
ee9775b
Compare
This was referenced Oct 27, 2019
Merged
e29976c
to
a8466ca
Compare
77e7e69
to
d3d9f07
Compare
072980a
to
c0eafc9
Compare
since inverse_mod is very computationally expensive (around 100 multiplications) it's cheaper to just bring the fractions to the same denominator
when loading public keys, perform the point verification just once when loading private keys, do not verify the derived public point
make all test cases execute in less than 0.3s on i7 4790K
don't treat the universal code for point addition specially
since this avoids creating new PointJacobi after every addition it makes the signing about 20% faster
looks like few merges/rebases didn't go exactly as planned and ended up duplicating test code, remove it
since some branching in hypothesis strategies and in handling different python, hypothesis, openssl and unittest versions is necessary, ignore them for branch coverage remove benchmarking code and dead code from test_pyecdsa.py (we have speed.py now) and exclude a disabled test case from coverage
the x and y needs to be on curve, so they need to be smaller than the curve's prime, not the base point order See Section 3.2.2.1 of SEC 1 v2
since multiplying a point by the order is farily expensive, skipping it (when safe to do so) greatly increases performance does not increase the speed.py numbers as point verification happens outside the signing and verifying operations
since on older distros like CentOS 6 there is python-gmpy but not python-gmpy2, support gmpy too
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.
Use Jacobi representation for internal calculations. Precompute point doublings for curve generators and public keys. Use 2-ary Non-Adjacent Form for multiplication (both for regular and precomputed points).
ver 0.14.1:
this branch:
for comparison, OpenSSL on same machine achieves:
(OpenSSL has hand-optimised assembly with AVX for
nistp256
/NIST256p
curve)depends on #126, fixes #94 (while there are more efficient algorithms still, being 3.6 times slower than generic C implementation for verification and 33% slower for signing is acceptable to me 😄 )
or when gmpy2 is used, being like 7% slower for verify and more than 2 times faster for signing 😁
To do:
gmpy
andgmpy2
that work for us, specify them insetup.py