Now that we have extracted the release changes from the
zcash/librustzcash subtree, we are no longer in a workspace with
relative paths to these dependencies.
We were already ignoring the actual bit length of the scalar, and
selecting the window size based on the maximum bit length, which
effectively hard-coded a window size of 4.
The generic API now only guarantees that the torsion component is
cleared deterministically; group elements may be multiplied by multiples
of the cofactor (not necessarily the actual cofactor), as long as the
choice of multiplier is fixed for a given implementation.
Wnaf was originally generic over CurveProjective; in the prior refactor
commit, we renamed this to CofactorCurve. But w-NAF only requires scalar
multiplication, which is provided by the Group trait, so we relax the
bounds on Wnaf to enable it to be used with any group. We move the
generic w-NAF helper methods from the Curve trait to a new WnafGroup
extension trait, to keep the w-NAF API surface self-contained, and not
expose it to users who aren't using it.
Instead of having the Group crate hold a Subgroup associated type (and
thus needing to define the subgroup of a prime-order group as itself),
we specify two separate sets of traits for prime-order groups and ones
with a cofactor.
Protocol implementors can either restrict their implementations to only
work with PrimeGroup, or can explicitly choose to support CofactorGroup
and then explicitly handle the subgroup edge cases with e.g.
CofactorGroup::mul_by_cofactor (which would be a no-op for PrimeGroup).
Protocol implementors can also choose to specialise to elliptic curves
if they want to leverage an affine representation and mixed addition in
their protocol for efficiency, or they can ignore those traits and stick
with the simpler group-focused traits.
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.
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.
The GroupOps trait represents the group operation (addition), and the
combination of the group operation with group inversion (subtraction).
Group inversion (negation) is constrained directly on the Group trait.
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.
ebfull
Jack Grigg
Jack Grigg