| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
EC_POINT_mul() has a complex multi-use interface - there are effectively
three different ways it will behave, depending on which arguments are NULL.
In the case where we compute g_scalar * generator + p_scalar * point, the
mul_double_nonct() function pointer is called, however only g_scalar,
p_scalar and point are passed - it is expected that the lower level
implementation (in this case ec_wnaf_mul()) will use the generator from
the group.
Change mul_double_nonct(), ec_mul_double_nonct() and ec_wnaf_mul() so that
they take scalar1, point1, scalar2 and point2. This removes all knowledge
of g_scalar and the generator from the multiplication code, keeping it
limited to EC_POINT_mul(). While here also consistently pass scalar then
point, rather than a mix of scalar/point and point/scalar.
ok tb@
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an implementation detail and there is no reason to leak it from
the library.
This removes EC_GFp_{mont,simple}_method(), EC_GROUP_{method_of,new}(),
EC_METHOD_get_field_type(), EC_POINT_method_of() from the public API.
EC_GROUP_copy() is now quite useless, so it will go as well.
ok jsing
|
|
|
|
|
|
|
|
| |
This removes the penultimate internal call of BN_MONT_CTX_new(). The last
one could be removed at the cost of introducing a BN_MONT_CTX_dup(), which
probably isn't worth it.
ok jsing
|
|
|
|
| |
ok jsing
|
|
|
|
| |
ok jsing
|
|
|
|
|
|
|
|
|
| |
There's no need for a separate mul_generator_ct() function pointer - we
really only need mul_single_ct() and mul_double_nonct(). And rather than
calling ec_mul_ct() and having it figure out which point to use, explicitly
pass the generator point when calling mul_single_ct().
ok tb@
|
|
|
|
| |
These somehow escaped a prior pass.
|
|
|
|
|
|
|
| |
This helped a bit with readability when we needed to do &group->p, but now
that's no longer needed.
discussed with jsing
|
|
|
|
|
|
|
|
| |
Add wrapper functions that call the methods so that we can get rid of
inconsistent use of ugly function pointers with massively overlong lines
and other ways of reaching into the methods.
ok jsing
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Rename ec_is_on_curve() to ec_point_is_on_curve() and ec_cmp() to
ec_point_cmp().
|
|
|
|
|
| |
These were in the middle of the methods responsible for curve operations,
which makes little sense.
|
|
|
|
|
|
|
|
| |
Now that it is method-agnostic, we can remove the method and move the
implementation to the body of the public API function. And another
method goes away. We're soon down to the ones we really need.
discussed with jsing
|
|
|
|
|
|
|
|
|
|
| |
While this is nicely done, it is a bit too clever. We can do the
calculation in the normal domain rather than the Montgomery domain
and this way the method becomes method agnostic. This will be a bit
slower but since a couple of field operations are nothing compared
to the cost of BN_mod_sqrt() this isn't a concern.
ok jsing
|
|
|
|
| |
discussed with jsing
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
EC_POINTs_mul() was only ever used by Ruby and they stopped doing so for
LibreSSL when we incorporated the constant time multiplication work of
Brumley et al and restricted the length of the points array to 1, making
this API effectively useless. The only real reason you want to have an
API to calculate \sum n_i P_i is for ECDSA where you want m * G + n * P.
Whether something like his needs to be in the public API is doubtful.
EC_POINTs_make_affine() is an implementation detail of EC_POINTs_mul().
As such it never really belonged into the public API.
ok jsing
|
|
|
|
|
|
|
|
|
|
| |
Whatever the EC_METHOD, this will always be equivalent to getting and
setting the affine coordinates, so this needs no dedicated method.
Also, this is a function that makes no real sense since a caller should
never need to care about this... As always, our favorite language bindings
thought they might have users who care. This time it's Ruby and Perl.
ok jsing
|
|
|
|
|
|
|
|
|
|
| |
After possibly decoding a and b in EC_GROUP_get_curve(), this is a pure
calculation in GFp and as such doesn't make use of any method-specifics.
Let's perform this calculation directly in the public API implementation
rather than redirecting through the methods and remove yet another method
handler.
ok jsing
|
| |
|
|
|
|
|
|
|
| |
The degree made some sense when EC2M was a thing in libcrypto. Fortunately
that's not the case anymore. The order handler never made sense.
ok jsing
|
|
|
|
|
|
| |
This is another bit of indirection that makes this code so hard to follow.
ok jsing
|
| |
|
|
|
|
|
|
|
| |
This is usually method specific, so remove the indirection and call the
appropriate blinding function directly.
ok tb@
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is only used by ec_points_make_affine(), which is only used by the
wNAF multiplication, which is only used by ECDSA. We can afford computing
that one once per ECDSA verification given the cost of the rest of this.
Thus, the field_set_to_one() member disappears from the EC_METHOD and the
mont_one member disappears from EC_GROUP and with it all the complications
when setting/copying/freeing the group.
ok jsing
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
That the BN-driven EC code uses Jacobian projective coordinates as an
optimization is an implementation detail. As such this should never have
leaked out of the library as part of the public API. No consumer should
ever care and if they do they're doing it wrong. The only port that cares
is one of those stupid little perl modules that expose all the things and
transform terrible OpenSSL regress tests into similarly horrible Perl.
In practice, only affine coordinates matter (perhaps in compressed form).
This prunes two more function pointers from EC_GROUP and prepares the
removal of the field_set_to_one() method which is now only used in
ec_points_make_affine().
ok jsing sthen
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The only way to get an EC_GROUP or an EC_POINT is by calling the relevant
_new() function and to get rid of it, something must call _free(). Thus we
can establish the invariant that every group has Weierstrass coefficients
p, a, b as well as order and cofactor hanging off it. Similarly, Every
point has allocated BIGNUMs for its Jacobian projective coordinates.
Unfortunately, a group has the generator as an optional component in
addition to seed and montgomery context/one (where optionality makes
more sense).
This is a mostly mechanical diff and only drops a few silly comments and
a couple of unnecessary NULL checks since in our part of the wrold the
word invariant has a meaning.
This should also appease Coverity who likes to throw fits at calling
BN_free() for BIGNUM on the stack (yes, this is actually a thing).
ok jsing
|
|
|
|
|
|
|
| |
There is only one caller, EC_GROUP_free(), so inline the relevant free
calls there and dispose of a few layers of indirection.
ok jsing
|
|
|
|
|
|
|
|
| |
For both in-tree methods these are just complicated ways of zeroing part
of the group object. The group is allocated with calloc(), so it's all
entirely pointless.
ok jsing
|
| |
|
|
|
|
|
|
| |
Now that we only do curves over GF(p) fields, there's no need to use a
weird, confusing name for what we usually call p. Adjust some comments
in the vicinity as well.
|
|
|
|
| |
discussed with jsing
|
|
|
|
|
|
|
|
|
| |
Like most of the "group" methods these are shared between Montgomery
curves and simple curves. There's no point in five methods hanging off
the EC_METHODS struct whne they can just as well be inlined in the
public API. It makes all files involved shorter...
ok jsing
|
|
|
|
|
|
|
|
| |
While there likely won't be enough BNs already available in the ctx, and
thus it won't greatly reduce the amount of allocated BNs, it simplifies
the exit path quite a bit.
review feedback from jsing
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is unclear how the original code was supposed to work. It clearly
missed a few corner cases (like handling points at infinity correctly)
and the badly mangled comment that was supposed to display a binary
search tree didn't help at all.
Instead do something much more straightforward: multiply all the non-zero
Z coordinates of the points not at infinity together, keeping track of the
intermediate products. Then do a single expensive modular inversion before
working backwards to compute all the inverses. Then the transformation from
Jacobian coordinates to affine coordiantes (x, y, z) -> (x/z^2, y/z^3, 1)
becomes cheap. A little bit of care has to be taken for Montgomery curves
but that's very simple compared to the mess that was there before.
ok jsing
This is a cleaned up version of:
commit 0fe73d6c3641cb175871463bdddbbea3ee0b62ae
Author: Bodo Moeller <bodo@openssl.org>
Date: Fri Aug 1 17:18:14 2014 +0200
Simplify and fix ec_GFp_simple_points_make_affine
(which didn't always handle value 0 correctly).
Reviewed-by: emilia@openssl.org
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The only caller passes in num = 1 and is itself called in a path that
ensures that the multiplier of the generator is != NULL. Consequently
we don't need to deal with an array of points and an array of scalars
so rename them accordingly.
In addition, the change implies that numblocks and num_scalar are now
always 1, so inline this information and take a first step towards
disentangling this gordian knot.
ok jsing
|
|
|
|
| |
spotted by jsing
|
| |
|
| |
|
|
|
|
|
| |
These functions are no longer shared between multiple files, so they can
be static in ecp_methods.c and the long list of prototypes can go away.
|
| |
|
| |
|
|
While not the greatest of names, ecp_methods.c is better than ecp_smpl.c.
It matches the naming ecx_methods.c and in a subsequent commit it will
become the new home of the stuff in ecp_mont.c as well.
discussed with jsing
|