Specifications of deployed elliptic curves fall into one of two
categories:
- They specify both compressed and uncompressed encodings, allowing
implementations to use either depending on performance vs data size
considerations.
- They specify a single point encoding format using point compression.
I am unaware of any elliptic curve specification that explicitly forbids
compressed encodings.
To support both categories of elliptic curves, we provide the
CurveAffine::Compressed associated type which all curves must define,
and then curves that additionally specify an uncompressed encoding may
implement the UncompressedEncoding trait and its Uncompressed associated
type.
pairing::PairingCurveAffine continues to require that its groups provide
uncompressed encodings, because this is relied upon by bellman::groth16.
We can revisit this restriction when that module is refactored as a
separate crate.
This enables MultiMillerLoop to be conditionally implemented, for
example in libraries where Engine::pairing supports no-std, but
MultiMillerLoop requires an allocator.
These associated types were completly unused. The only place we need
information about the base field of an elliptic curve is inside Jubjub
when operating over its coordinates to implement EC math inside the
circuit, and we can handle that either concretely, or with a future
trait specifically for that use-case.
Instead of imposing the requirement that bellman users explicitly
specify an engine for every proving system, we allow the Rust type
system to figure it out for us. An engine is specifically useful in
places where we require defined relationships between several types;
ff::ScalarEngine only has one type, and thus any usage of it can be
trivially replaced by an explicit Scalar type. This is also more
readable :)
Replaced by explicit APIs on the CurveAffine trait.
GroupDecodingError has been moved into pairing::bls12_381::ec, as it is
no longer used by the group traits.
Replaces the mutating CurveProjective::batch_normalization API, and
removes the need for CurveProjective::is_normalized.
The new temporary implementation in pairing::bls12_381::ec is adapted
from bls12_381::g1.
Group represents a cryptographic group with a large prime-order subgroup
and a small cofactor. PrimeGroup further constrains the group to have a
cofactor of one.
ff_derive still implements Ord and PartialOrd for the fields it
implements, because pairing::bls12_381 internally assumes that those are
implemented. Once we delete that implementation, we will remove the Ord
and PartialOrd implementations from ff_derive.
This enables generic code to reliably operate on the bits of an encoded
field element, by converting them to and from a known (little)
endianness.
The BitAnd and Shr bounds on PrimeField are now removed, as users can
perform these operations themselves as needed.
The sqrt() function is now part of the Field trait. ff_derive returns an
error on fields for which it does not support generating a square root
function.
Note that Fq6 and Fq12 in pairing::bls12_381 leave the function
unimplemented. They will be dropped once the migration to the bls12_381
crate is complete. The equivalent structs in that crate are not exposed.
The trait is implemented by default for u8 and u64, allowing pow_vartime
to be used with both the byte encoding and limb representation of field
elements.
Jack Grigg