-
Notifications
You must be signed in to change notification settings - Fork 228
elliptic-curve: refactor field element decoding/encoding #1220
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
Merged
tarcieri
merged 1 commit into
master
from
elliptic-curve/refactor-field-element-encoding
Jan 27, 2023
Merged
elliptic-curve: refactor field element decoding/encoding #1220
tarcieri
merged 1 commit into
master
from
elliptic-curve/refactor-field-element-encoding
Jan 27, 2023
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
d7d0fe4 to
00fbf4c
Compare
Previously `FieldBytes` was defined in terms of `C::Uint::ByteSize`, which lead to it being improperly sized for curves with unusual modulus sizes like P-224 and P-521 (which aren't multiples of 64). This commit adds an associated `C::FieldBytesSize` which makes it possible to specifically define the size of a serialized field element. The previous `FieldSize<C>` type alias is retained as `FieldBytesSize`, which handles specifying that the associated type should be accessed using `Curve::FieldBytesSize`. To handle potential discrepancies between `C::Uint::ByteSize` and `C::FieldBytesSize`, provided `Curve::decode_field_bytes` and `Curve::encode_field_bytes` methods have been added for handling decoding/encoding serialized field elements to/from `C::Uint`. The methods use a default big endian serialization. Now that curves can customize the endianness used for encoding field elements, this eliminates the need to have separate `from_be_bytes`/`from_le_bytes` and `to_be_bytes`/`to_le_bytes` methods. Instead the endianness can be known a priori, which eliminates the need for the caller to select a specific endianness. As such, this PR folds these methods (defined on e.g. `ScalarPrimitive` and `NonZeroScalar`) into `from_bytes` and `to_bytes`.
00fbf4c to
c6ef655
Compare
tarcieri
added a commit
that referenced
this pull request
Jan 27, 2023
Removes all methods from `Reduce` except the newly renamed `Reduce::reduce` (formerly `from_uint_reduced`). This follows #1220 which changed APIs to handle discrepancies between the serialized size of the big integer type used to represent field elements and the on-the-wire serialization which respects the size of the curve's field modulus and order.
tarcieri
added a commit
that referenced
this pull request
Jan 27, 2023
Removes all methods from `Reduce` except the newly renamed `Reduce::reduce` (formerly `from_uint_reduced`). This follows #1220 which changed APIs to handle discrepancies between the serialized size of the big integer type used to represent field elements and the on-the-wire serialization which respects the size of the curve's field modulus and order.
tarcieri
added a commit
to RustCrypto/signatures
that referenced
this pull request
Jan 29, 2023
Bumps the `elliptic-curve` crate to the latest prerelease on crates.io. Notably this includes changes to how `FieldBytes` is encoded made with the goal of supporting elliptic curves with unusual moduli such as P-224 and P-521: RustCrypto/traits#1220
tarcieri
added a commit
to RustCrypto/signatures
that referenced
this pull request
Jan 29, 2023
Bumps the `elliptic-curve` crate to the latest prerelease on crates.io. Notably this includes changes to how `FieldBytes` is encoded made with the goal of supporting elliptic curves with unusual moduli such as P-224 and P-521: RustCrypto/traits#1220
tarcieri
added a commit
to RustCrypto/signatures
that referenced
this pull request
Jan 29, 2023
Bumps the `elliptic-curve` crate to the latest prerelease on crates.io. Notably this includes changes to how `FieldBytes` is encoded made with the goal of supporting elliptic curves with unusual moduli such as P-224 and P-521: RustCrypto/traits#1220
Merged
scv35
added a commit
to scv35/Signature-algorithms
that referenced
this pull request
Jul 4, 2025
Bumps the `elliptic-curve` crate to the latest prerelease on crates.io. Notably this includes changes to how `FieldBytes` is encoded made with the goal of supporting elliptic curves with unusual moduli such as P-224 and P-521: RustCrypto/traits#1220
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.
Previously
FieldByteswas defined in terms ofC::Uint::ByteSize, which lead to it being improperly sized for curves with unusual modulus sizes like P-224 and P-521 (which aren't multiples of 64).This commit adds an associated
C::FieldBytesSizewhich makes it possible to specifically define the size of a serialized field element. The previousFieldSize<C>type alias is retained asFieldBytesSize, which handles specifying that the associated type should be accessed usingCurve::FieldBytesSize.To handle potential discrepancies between
C::Uint::ByteSizeandC::FieldBytesSize, providedCurve::decode_field_bytesandCurve::encode_field_bytesmethods have been added for handling decoding/encoding serialized field elements to/fromC::Uint.The methods use a default big endian serialization. Now that curves can customize the endianness used for encoding field elements, this eliminates the need to have separate
from_be_bytes/from_le_bytesandto_be_bytes/to_le_bytesmethods. Instead the endianness can be known a priori, which eliminates the need for the caller to select a specific endianness. As such, this PR folds these methods (defined on e.g.ScalarPrimitiveandNonZeroScalar) intofrom_bytesandto_bytes.