Skip to content

Conversation

@tarcieri
Copy link
Member

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.

@tarcieri tarcieri force-pushed the elliptic-curve/refactor-field-element-encoding branch from d7d0fe4 to 00fbf4c Compare January 27, 2023 17:40
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`.
@tarcieri tarcieri force-pushed the elliptic-curve/refactor-field-element-encoding branch from 00fbf4c to c6ef655 Compare January 27, 2023 17:43
@tarcieri tarcieri merged commit 462d35f into master Jan 27, 2023
@tarcieri tarcieri deleted the elliptic-curve/refactor-field-element-encoding branch January 27, 2023 17:47
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
@tarcieri tarcieri mentioned this pull request Mar 1, 2023
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
@c410-f3r c410-f3r mentioned this pull request Jul 24, 2025
1 task
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants