This reverts commit 804dab8924, reversing
changes made to 5d15ca77ff.
This is due to a (previously undocumented) contract on the behaviours of
(potentially unreduced mod \ell) "packed" scalars w.r.t. to the manner in which
their bytes are interpreted.
Upon documentation fixes and corresponding fixes being made on top of the
floodyberry/optimized_scalar branch, this revert will again be reverted and then
the additional changes merged (à la
file:///usr/share/doc/git/html/howto/revert-a-faulty-merge.html).
Signed-off-by: Isis Lovecruft <isis@patternsinthevoid.net>
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.
