openbsd/src/lib/libcrypto/ec/ec_mult.c, branch OPENBSD_7_9A mirror of https://github.com/libressl/openbsd.git
https://git.lua4.win/openbsd/atom?h=OPENBSD_7_92025-12-26T18:44:19+00:00Replace 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
ec_mult.c: place this code under my ISC license2025-08-26T14:14:52+00:00tb2025-08-26T14:14:52+00:00urn:sha1:b54b551b03de5db0750e0fffc1a4ad3389fd28d3
I have effectively rewritten the entirety of this file end of 2024.
This isn't code I'm particularly proud of, but it's much better than
it was before (it's not as if that involved any sort of challenge...)
requested by/ok jsing
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@
Neuter the EC_POINTs_* API2025-01-11T13:58:31+00:00tb2025-01-11T13:58:31+00:00urn:sha1:9eb2037cacec84495df31a5fe13e451de3340724
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
ec_mult: use 1ULL to avoid C4334 warning on Visual Studio2024-12-19T21:05:46+00:00tb2024-12-19T21:05:46+00:00urn:sha1:d6c5649508f2d8d80a4192f5d9d2b66e8cc247f3
The shift is between 0 and 5 bits, so it doesn't matter, but VS is short
for very st...ubborn as are its users when it comes to reporting non-issues
ec_mult: forgot to make one helper static2024-12-07T13:49:43+00:00tb2024-12-07T13:49:43+00:00urn:sha1:5577b2fcde8eefb9fd237dae31de9f4614fcd372Move initialization of sign out of the middle of bits handling2024-12-07T13:32:07+00:00tb2024-12-07T13:32:07+00:00urn:sha1:1a524c98b12d0c956efd3bc3da96a8d79cf10098Rename ec_wNAF_mul() to ec_wnaf_mul()2024-12-06T15:49:37+00:00tb2024-12-06T15:49:37+00:00urn:sha1:e2a74b965777b01542143e9198f28a6620f9f4f0
discussed with jsing
ec_mult: manage wNAF data in a struct2024-12-06T15:39:59+00:00tb2024-12-06T15:39:59+00:00urn:sha1:bf1c7309b6363f22dd0686c08480b282aef894a4
This refactors the wNAF multiplication further and introduces a small API
that manages the wNAF digits for bn and the multiples of digit * point in
a single struct that is initialized and freed in two API calls in the main
function, ec_wNAF_mul(). This way the main algorithm is no longer cluttered
with logic to keep various arrays in sync, helper functions calculating the
wNAF splitting of bn and multiples of the point do not need to deal with
memory management, and a pair of accessors obviates previously missing
bounds checking.
At this point we have reached a relatively clean and straightforward wNAF
implementation that fits precisely the purpose needed in libcrypto, i.e.,
ECDSA verification instead of being generalized and optimized to the max
for no good reason apart from endowing the author with an academic degree.
Popper's famous maxim "if you can't say it clearly, keep quiet, and keep
working until you can" very much applies to code as well. In other words,
shut up and hack (and don't pour too much energy into commit messages, tb).
ok jsing