-
Notifications
You must be signed in to change notification settings - Fork 478
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
Split out and clean scalar multiplication code #120
Merged
isislovecruft
merged 9 commits into
dalek-cryptography:develop
from
hdevalence:feature/refactor-scalar-mul_r1
Apr 2, 2018
Merged
Split out and clean scalar multiplication code #120
isislovecruft
merged 9 commits into
dalek-cryptography:develop
from
hdevalence:feature/refactor-scalar-mul_r1
Apr 2, 2018
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
This should contain generic implementations of scalar multiplication algorithms that can be used with multiple backends. The goal is to move the existing scalar multiplication code into this submodule, then call it from the user-facing API. This can also contain code for things we can't do now, like multiscalar multiplication with precomputation.
The serial (`u32`/`u64`) implementations use a multiple curve models, passing between extended and projective coordinates when performing addition and doubling (respectively). But the AVX2 backend doesn't, so in order to write a single scalar mult implementation, we have to either abstract over the curve models or have two implementations. A generic solution is possible but extremely unreadable: the scalar mul implementation would be parameterized over the point types used by the serial implementations, with many where clauses describing how the types relate. The AVX2 types could then be substituted in the appropriate places. Instead we just duplicate the code into the `avx2` backend.
This was faster than the non-AVX2 code, but the serial code is already so fast that there's no reason not to use it.
Only the readdition formulas are actually used by scalar multiplication, so there's no reason to implement vectorized addition.
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.
LGTM, thanks!
pinkforest
pushed a commit
to pinkforest/curve25519-dalek
that referenced
this pull request
Jun 27, 2023
* Updated to new curve25519 scalar API * Removed clamping from constructors; clamping is always done during scalar-point multiplication * Updated test to reflect new functionality * Updated changelog
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.
Creates a new
scalar_mul
module hierarchy. The goal is to move the existing scalar multiplication code into this submodule, then call it from the user-facing API.This can also contain code for things we can't do now, like multiscalar multiplication with precomputation, or multiscalar multiplication targeting large problem sizes (e.g., like the ones used for Bulletproofs).
The serial (
u32
/u64
) implementations use a multiple curve models, passing between extended and projective coordinates when performing addition and doubling (respectively). But the AVX2 backend doesn't, so in order to write a single scalar mult implementation, we have to either abstract over the curve models or have two implementations.A generic solution is possible but extremely unreadable (see this experiment): the scalar mul implementation would be parameterized over the point types used by the serial implementations, with many where clauses describing how the types relate. The AVX2 types could then be substituted in the appropriate places.
Instead of doing that, this duplicates the scalar mul code into the
avx2
backend. But this allows changing the algorithms (e.g. window sizes) as is optimal there.The existing AVX2 code is split into the same hierarchy. The fixed-base code is removed. This was faster than the non-AVX2 code, but the serial code is already so fast that there's no reason not to use it. The vectorized point addition is removed -- only the readdition formulas are actually used by scalar multiplication, so there's no reason to implement vectorized addition. The variable-time code is slightly faster now since it uses readdition: for instance, this is a size-128 multiscalar mul.