openbsd/src/lib/libcrypto/ec/ec_key.c, branch OPENBSD_7_9_BASEA mirror of https://github.com/libressl/openbsd.git
https://git.lua4.win/openbsd/atom?h=OPENBSD_7_9_BASE2026-03-18T08:02:40+00:00libcrypto: prefix EC_KEY methods with ec_key_2026-03-18T08:02:40+00:00tb2026-03-18T08:02:40+00:00urn:sha1:e1991105df8fe12032795b7f34ed61fd9272e525
We received reports that the too generic internal ecdsa_{sign,verify}()
symbol names clash in some static links. The naming here is annoying
because the EC_KEY_METHOD amalgamated the no longer existing ECDH and
ECDSA methods which themselves had poorly chosen method names, still
reflected in public API.
There are various messes here. The ECDSA verify methods are declared
in ec_local.h, whereas the ECDSA sign methods are in ecdsa_local.h
(which is itself pretty useless and really only about EC_KEY_METHOD).
I therefore merged the ECDSA method declarations into ec_local.h and
deleted ecdsa_local.h since I see no real benefit to the latter.
ecdsa.c needs ec_local.h anyway. Having the method declarations next
to EC_KEY_METHOD seems sensible. I left the order as it was, matching
ecdsa.c. The eckey_compute_pubkey() prototype should probably be moved
down.
With one exception I just added an ec_key_ prefix. This leads to a
a repetition of 'key' in ec_key_ecdh_compute_key() which I chose to
live with because it matches the public ECDH_compute_key() (mostly
used by SSH implementations). The exception is ec_key_generate_key()
where I expanded the gen() leading to another _key repetition but
this then matches EC_KEY_generate_key().
Thanks to Rosen Penev for reporting and sending an initial diff.
See also https://github.com/gsliepen/tinc/issues/478
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
Make EC_KEY_precompute_mult() return 1 directly2025-01-25T10:34:36+00:00tb2025-01-25T10:34:36+00:00urn:sha1:a7fa53eebe25c69f2a0781c3215904eb9a28db0b
This hasn't done anything in a long time. Only dovecot uses an unchecked
call to this. With this we can remove EC_GROUP_precompute_mult().
ok jsing
ec_key_gen() is unused outside ec_key.c, so make it static2025-01-11T20:57:03+00:00tb2025-01-11T20:57:03+00:00urn:sha1:5b447c48da016a6d20470f6a1f1b223541c3738fMove EC_KEY_METHOD_DYNAMIC next to the two methods using it2025-01-11T20:55:08+00:00tb2025-01-11T20:55:08+00:00urn:sha1:c13433b3ce1073b770e3b23c4779ae36f71c1442
Only EC_KEY_METHOD_{new,free}() need to know about this flag, so make
that more obvious.
Merge ec_kmeth into ec_key2024-11-16T10:38:10+00:00tb2024-11-16T10:38:10+00:00urn:sha1:b1f07f73ab7656f59ffa98b14ae58c3676daf4b3EC_KEY_copy() don't leave stale private keys in place2024-11-15T08:49:07+00:00tb2024-11-15T08:49:07+00:00urn:sha1:2fccd030cb43ee63680342ece2969aa605002276
As most other objects, EC_KEYs can be as sparsely and invalidly populated
as imagination permits and the competent designers of EC_KEY_copy() chose
to just copy over what's available (yeah, what kind of copy is that?) and
leave in place what happens to be there. In particular, if the dest EC key
was used with a different group and has a private key, but the source key
doesn't, the dest private key remains intact, as invalid, incompatible and
unusable as it may be. Fix this by clearing said private key.
ok jsing
Clean up EC_KEY_dup()2024-11-08T22:10:18+00:00tb2024-11-08T22:10:18+00:00urn:sha1:aef80d57f4c4c17e8936fb0426aca8800f62d831
This calls init() with the default method, so EC_KEY_copy() gets a chance
to call finish() if the source's method doesn't match. But no init() call
is made in EC_KEY_copy(). Of course the source method's copy() needs to be
able to cope. The great news is that ssh uses this. Sigh.
ok beck jsing
Sweep over EC_KEY_copy()2024-11-08T22:03:29+00:00tb2024-11-08T22:03:29+00:00urn:sha1:39f8f36dfe04018fa4552dbd91ead07c80a7fafe
This is a special snowflake. Its logic is such that it only overwrites
things on the target that are available in the source. So if the source
has no group (yes, that's possible), the destination's group will remain.
Even better: if you copy a public key over what was previously a private
key, the private scalar will remain. That's almost never going to result
in a valid key. If you copy from a larger group to a smaller group the
private scalar will most likely be out of range [1, order).
Use dup functions instead of reimplementing badly and add a snarky comment
courtesy of beck to one of those silly const annotations (there's a small
addendum by me).
ok beck jsing
Clean up EC_KEY_free2024-11-08T21:56:58+00:00tb2024-11-08T21:56:58+00:00urn:sha1:de6bfd564bb65a46744c9bedbd05b88a1376169d
r is a silly name for an EC_KEY and it is silly to assign the refcount
to a variable i (short for uninspired) when you can check the function
return directly. Tweak sizeof in freezero to jsing's liking.
ok beck jsing