This begins to attempt to restructure the source tree so that the common parts
are common and the different parts are different.
The backend is now split into two parts:
- serial (containing the implementation using serial formulas and mixed-model arithmetic).
- vector (containing the implementation using parallel formulas and single-model arithmetic).
The serial scalar_mul tree is now under backend::serial::scalar_mul.
The avx2 scalar_mul tree is now under backend::avx2::scalar_mul.
`FieldElement32` -> `FieldElement2625`
`FieldElement64` -> `FieldElement51`
`Scalar32` -> `Scalar29`
`Scalar64` -> `Scalar52`
This naming is more accurate and would let us add an ADX backend later.
Each backend can now be selected by an individual feature:
- `u32_backend` for `backend::u32`;
- `u64_backend` for `backend::u64`;
- `avx2_backend` for `backend::avx2`;
The `u64_backend` is selected by default, since most people use X64 and we have
no way to select based on target (see discussion in #126). However, these
changes mean that it is possible to select the backend explicitly, and if we
had the ability to select target-default features, we could do so easily.
The `MontgomeryPoint` struct is now a point on the Kummer line of the Montgomery curve.
The `ProjectivePoint` struct is made private, since its only purpose is
internal to the Montgomery ladder.
The Montgomery ladder takes affine input, making it faster, and produces affine output.
The Edwards-Montgomery correspondence is simplified.
These were originally added in 32da4c7d50
to implement Scalar negation in terms of multiply-add.
But we have a full implementation of scalar arithmetic now, so it's not
necessary to keep the constants around.
This commit defines a Scalar to hold an integer representing an element of
Z/lZ. Applications like X/Ed25519 that care about the bit-patterns of the
scalars they use can set a specific bit-pattern using the `from_bits`
constructor. Applications that want to treat scalars as integers mod l can use
the `from_bytes_mod_order` constructor. Either way, the constructor ensures
that the integer representing each Scalar is bounded by 2^255 so that the high
bit is set. This means that any Scalar object is always safe to use for scalar
multiplication, while maintaining compatibility with both the Ristretto
use-case and the X/Ed25519 usecase.
Having _BASEPOINT_TABLE and _BASEPOINT_POINT means that it's not possible to
use the slow, generic scalar mult in place of the fast, precomputed scalar
mults.
Split the field arithmetic implementations into `FieldElement`,
`FieldElement32`, and `FieldElement64`. `FieldElement` is a type alias for one
of `FieldElement32` or `FieldElement64`, depending on feature selection.
`field.rs` contains tests and code which is generic with respect to the
implementation (e.g., inversions), while `field_32bit.rs` and `field_64bit.rs`
contain the implementation-specific code.
The implementation is not completely hidden, since `FieldElement32` and
`FieldElement64` are tuple structs whose elements are public; `pub(crate)`
doesn't seem to work for tuple structs.
Similarly, the constants file is split over multiple files, depending on the
implementation.
