compress_edwards() is now named compress() and works only on points
which are in Edwards form. Similarly, compress_montgomery() is now
also called compress(), and it only works on point already in
Mongomery form.
To switch between forms, use to_montgomery().
Conversion from Montgomery directly to Edwards is not yet implemented.
* CHANGE the API requested in
https://github.com/isislovecruft/curve25519-dalek/issues/47,
hopefully for the better.
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.
libcollections was recently merged into liballoc:
https://github.com/rust-lang/rust/pull/42648
I went ahead and also added an "alloc" feature which no_std users can use to opt
into liballoc features (i.e. any code using Vec). This should have no effect on
anything but no_std usage. It does make it possible for people without
allocators to use curve25519-dalek if they want though. Might be nice for
"bare metal" development.
All that said, from what I can gather liballoc, while not "stable", should
likely stick around for the forseeable future.
Some backstory on the liballoc/libcollections merge here:
https://github.com/rust-lang/rust/pull/42565
