openbsd/src/lib/libcrypto/ec/ec_lib.c, branch OPENBSD_7_9_BASEA mirror of https://github.com/libressl/openbsd.git
https://git.lua4.win/openbsd/atom?h=OPENBSD_7_9_BASE2025-12-26T18:49:13+00:00Use group method on point_{set_to,is_at}_infinity()2025-12-26T18:49:13+00:00tb2025-12-26T18:49:13+00:00urn:sha1:c9338745181f31ae01336081edfdb738c0b76d5f
All other public APIs call group->meth->... not point->meth->...
Add compatibility check to EC_POINT_mul()2025-12-26T18:45:42+00:00tb2025-12-26T18:45:42+00:00urn:sha1:0e28e8b910443b64c021ba44af8042b9ae325e5c
This is the only public API that doesn't check for compatibility between
group and point. Add the missing check.
ok jsing kenjiro
Replace group->meth != point->meth checks2025-12-26T18:44:19+00:00tb2025-12-26T18:44:19+00:00urn:sha1:e568a255270032a6a88715db4e3609b6129702ed
The method will currently always be identical since all groups use the
EC_GFp_mont_method(). Use the ec_group_and_point_compatible() check to
ensure this and if both group and point have a nid set, check that they
are identical.
ok jsing kenjiro
Add ec_group_and_point_compatible() helper2025-12-26T18:42:33+00:00tb2025-12-26T18:42:33+00:00urn:sha1:6aad598b27692cde1ada140f0cf7be0f102d2c84
Check that a given group and point are reasonably compatible. First see
if they use the same method. Compare nids if both have nid != NID_undef.
ok jsing kenjiro
Add nid to EC_POINT for compat checking2025-12-26T18:41:05+00:00tb2025-12-26T18:41:05+00:00urn:sha1:9f98bd62b5811dc1239ca4a121b39c3d962c73c2
It is annoying that an EC_POINT does not really know on what EC_GROUP it
lives. Adding a refcount to EC_GROUP is slightly tricky, so instead use
a nid which we will know unless the group was constructed by hand.
ok jsing kenjiro
Copy EC_FIELD_MODULUS/EC_FIELD_ELEMENTs when copying groups and points.2025-08-02T15:47:27+00:00jsing2025-08-02T15:47:27+00:00urn:sha1:ad3c9e6996dc8c88567319b6291785b4c0bb15c4
ok tb@
Provide method specific functions for EC POINT infinity.2025-05-24T08:25:58+00:00jsing2025-05-24T08:25:58+00:00urn:sha1:cab63c063d816f7bdfc022c940ec9842e8308429
Provide method specific functions for EC_POINT_set_to_infinity() and
EC_POINT_is_at_infinity(). These are not always the same thing and
will depend on the coordinate system in use.
ok beck@ tb@
Use err_local.h rather than err.h in most places2025-05-10T05:54:39+00:00tb2025-05-10T05:54:39+00:00urn:sha1:41e8f99dd1625a9f0c80ce9d4383e95b18e85709
ok jsing
Explicitly pass group generator to mul_double_nonct() from EC_POINT_mul().2025-03-24T13:07:04+00:00jsing2025-03-24T13:07:04+00:00urn:sha1:865465694bb9f7950a0710e8d7667d2540779602
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@
Check group generator in EC_POINT_mul().2025-03-24T12:49:13+00:00jsing2025-03-24T12:49:13+00:00urn:sha1:572b48cb49edaff7e25c2a2130a6715142745223
When a non-NULL generator scalar is passed to EC_POINT_mul(), the group's
generator will be used in multiplication. Add a check that ensures that the
group generator is non-NULL, in order to avoid needing to handle this
elsewhere (currently in the lower level point multiplication code).
ok tb@