A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=master 2026-04-20T04:26:12+00:00 2026-04-20T04:26:12+00:00 tb 2026-04-20T04:26:12+00:00 urn:sha1:e4bc9bc7b9138edf0b9cbab71d97ecd0dd29c6ac 2026-03-18T08:02:40+00:00 tb 2026-03-18T08:02:40+00:00 urn: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 2026-02-08T12:34:05+00:00 tb 2026-02-08T12:34:05+00:00 urn:sha1:dcddb3ef0e5583a374e829f3039cf629c80e71d1 jsing prefers doing all computations first and comparing at the end. This means we do more work when we fail and no longer (ab)use err as an out label. Also split out one more helper. ok jsing 2026-01-18T10:07:44+00:00 tb 2026-01-18T10:07:44+00:00 urn:sha1:72cdd91797afb2b9796ee9f67324a53c5fc6effe This removes some complications due to handling the fast path for affine points and general points at the same time. The result is a bit more code but both paths should be much easier to follow. ok jsing kenjiro 2025-12-26T18:49:13+00:00 tb 2025-12-26T18:49:13+00:00 urn:sha1:c9338745181f31ae01336081edfdb738c0b76d5f All other public APIs call group->meth->... not point->meth->... 2025-12-26T18:45:42+00:00 tb 2025-12-26T18:45:42+00:00 urn: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 2025-12-26T18:44:19+00:00 tb 2025-12-26T18:44:19+00:00 urn: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 2025-12-26T18:42:33+00:00 tb 2025-12-26T18:42:33+00:00 urn: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 2025-12-26T18:41:05+00:00 tb 2025-12-26T18:41:05+00:00 urn: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 2025-12-15T12:09:46+00:00 tb 2025-12-15T12:09:46+00:00 urn:sha1:341829195e0c845cf26339768f275f021b69fedc While the latter is more general in that it also works on 1-complement achitectures, we don't care about that. Adjust documentation and the only error check for it in libcrypto. ok deraadt