elliptic-curve: expose AffineCoordinates::y
#1891
Merged
Conversation
This file contains hidden or 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
In the past we've deliberately avoided exposing the y-coordinate to prevent the possibility of things like invalid curve attacks, although with time we have exposed more and more to support things like alternative point compression formats. See #1237 for some history. We're now trying to use these traits with Edwards curves like Curve25519 (in `curve25519-dalek`) and Ed448-Goldilocks, which use compressed Edwards y-coordinates as their compressed point format. That requires y-coordinate access. As such, this changes the previous `y_is_odd` method, which was used to implement SEC1-like compressed points, to a full `fn y` which returns a serialized field element for the y-coordinate. Closes #1019
This is quite hard to express via the trait-based interface otherwise, which is needed for ECDSA recovery, at the very least. We can experiment with getting rid of this before the next release, but preserving it ensures this change isn't breaking for now.
For symmetry with `y_is_odd`. This is also useful for point compression using an Edwards y-coordinate.
tarcieri
added a commit
to RustCrypto/elliptic-curves
that referenced
this pull request
Jun 5, 2025
Companion PR to RustCrypto/traits#1891 which adds access to affine y-coordinates. Notably we've just added an Edwards curve with `ed448-goldilocks`, and these curves use compressed Edwards y-coordinates, so y-coordinate access is needed to even implement point compression generically for these curves.
tarcieri
added a commit
to RustCrypto/elliptic-curves
that referenced
this pull request
Jun 5, 2025
Companion PR to RustCrypto/traits#1891 which adds access to affine y-coordinates. Notably we've just added an Edwards curve with `ed448-goldilocks`, and these curves use compressed Edwards y-coordinates, so y-coordinate access is needed to even implement point compression generically for these curves. Note that due to #1229 it's currently not possible to impl the extened `AffineCoordinates API for the Decaf implementation in the `ed448-goldilocks` crate. This PR comments out the relevant code for now with a TODO to fix it.
Member
Author
|
With one minor hiccup, there's now a companion PR for this here: RustCrypto/elliptic-curves#1230 |
tarcieri
added a commit
to RustCrypto/elliptic-curves
that referenced
this pull request
Jun 5, 2025
Companion PR to RustCrypto/traits#1891 which adds access to affine y-coordinates. Notably we've just added an Edwards curve with `ed448-goldilocks`, and these curves use compressed Edwards y-coordinates, so y-coordinate access is needed to even implement point compression generically for these curves. Note that due to #1229 it's currently not possible to impl the extened `AffineCoordinates API for the Decaf implementation in the `ed448-goldilocks` crate. This PR comments out the relevant code for now with a TODO to fix it.
tarcieri
added a commit
to RustCrypto/elliptic-curves
that referenced
this pull request
Jun 5, 2025
Companion PR to RustCrypto/traits#1891 which adds access to affine y-coordinates. Notably we've just added an Edwards curve with `ed448-goldilocks`, and these curves use compressed Edwards y-coordinates, so y-coordinate access is needed to even implement point compression generically for these curves. Note that due to #1229 it's currently not possible to impl the extened `AffineCoordinates API for the Decaf implementation in the `ed448-goldilocks` crate. This PR comments out the relevant code for now with a TODO to fix it.
tarcieri
added a commit
to RustCrypto/elliptic-curves
that referenced
this pull request
Jun 5, 2025
Companion PR to RustCrypto/traits#1891 which adds access to affine y-coordinates. Notably we've just added an Edwards curve with `ed448-goldilocks`, and these curves use compressed Edwards y-coordinates, so y-coordinate access is needed to even implement point compression generically for these curves. Note that due to #1229 it's currently not possible to impl the extened `AffineCoordinates API for the Decaf implementation in the `ed448-goldilocks` crate. This PR comments out the relevant code for now with a TODO to fix it.
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.
In the past we've deliberately avoided exposing the y-coordinate to prevent the possibility of things like invalid curve attacks, although with time we have exposed more and more to support things like alternative point compression formats. See #1237 for some history.
We're now trying to use these traits with Edwards curves like Curve25519 (in
curve25519-dalek) and Ed448-Goldilocks, which use compressed Edwards y-coordinates as their compressed point format. That requires y-coordinate access.As such, this changes the previous
y_is_oddmethod, which was used to implement SEC1-like compressed points, to a fullfn ywhich returns a serialized field element for the y-coordinate.Closes #1019