elliptic-curve: make ToEncodedPoint fallible
#400
Closed
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
Closes #399. As discussed in the aforementioned issue, this changes `ToEncodedPoint` to be fallible, returning an `Option<EncodedPoint<C>>` with the expectation that `None` is returned for the additive identity (a.k.a. point-at-infinity) Brief background: originally it was not expected for `AffinePoint` to be able to encode the additive identity, however supporting it allowed for infallible conversions between `AffinePoint` <-> `ProjectivePoint`. Technically, according to SEC1 Section 2.3.3, the identity can be represented by the `Elliptic-Curve-Point-to-Octet-String` encoding by using a single NULL byte (i.e. `[0u8]`). However, this would have the disadvantage of complicating `EncodedPoint`, making APIs that are presently infallible fallible, and may be unexpected by end users of the traits. If there's a legitimate use case for supporting SEC1-encoded identity points, we can revisit this tradeoff, adding support for encoding the identity element to `EncodedPoint`, and making `ToEncodedPoint` infallible once again.
tarcieri
force-pushed
the
elliptic-curve/make-to-encoded-point-fallible
branch
from
8e0ba21 to
376c96f
Compare
tarcieri
commented
Dec 16, 2020
|
|
||
| fn try_from(public_key: &PublicKey<C>) -> Result<EncodedPoint<C>, Error> { | ||
| public_key.to_encoded_point(C::COMPRESS_POINTS).ok_or(Error) | ||
| } |
Member
Author
There was a problem hiding this comment.
These conversions could potentially remain infallible if we had PublicKey enforce the invariant that the inner point cannot be the additive identity.
That would require making PublicKey::from_affine fallible, which might make sense, and would nicely match the similar invariants of SecretKey, which wraps a NonZeroScalar.
All that said, I'd like to follow up on that in a separate PR.
Member
Author
|
Per continued discussion on #399, I think I'll retry this with a slightly different approach. |
tarcieri
added a commit
that referenced
this pull request
Dec 16, 2020
Closes #399. The `ToEncodedPoint` trait is infallible. We can either make it fallible (as attempted in #400) or add support for the SEC1 encoding for the identity point. This commit adds SEC1 support for identity, allowing `ToEncodedPoint` to remain infallible. Unfortunately breaking as it requires adding new enum variants and some method signature changes. However, that said, this should make the SEC1 implementation "complete" in that it implements the full `Elliptic-Curve-Point-to-Octet-String` encoding (and decoding).
tarcieri
added a commit
that referenced
this pull request
Dec 17, 2020
Closes #399. The `ToEncodedPoint` trait is infallible. We can either make it fallible (as attempted in #400) or add support for the SEC1 encoding for the identity point. This commit adds SEC1 support for identity, allowing `ToEncodedPoint` to remain infallible. Unfortunately breaking as it requires adding new enum variants and some method signature changes. However, that said, this should make the SEC1 implementation "complete" in that it implements the full `Elliptic-Curve-Point-to-Octet-String` encoding (and decoding).
Merged
tarcieri
pushed a commit
that referenced
this pull request
Jan 7, 2022
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.
Closes #399.
As discussed in the aforementioned issue, this changes
ToEncodedPointto be fallible, returning anOption<EncodedPoint<C>>with the expectation thatNoneis returned for the additive identity(a.k.a. point-at-infinity)
Brief background: originally it was not expected for
AffinePointto be able to encode the additive identity, however supporting it allowed for infallible conversions betweenAffinePoint<->ProjectivePoint.Technically, according to SEC1 Section 2.3.3, the identity can be represented by the
Elliptic-Curve-Point-to-Octet-Stringencoding by using a single NULL byte (i.e.[0u8]).However, this would have the disadvantage of complicating
EncodedPoint, making APIs that are presently infallible fallible, and may be unexpected by end users of the traits.If there's a legitimate use case for supporting SEC1-encoded identity points, we can revisit this tradeoff, adding support for encoding the identity element to
EncodedPoint, and makingToEncodedPointinfallible once again.cc @rozbb @fjarri