A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=OPENBSD_7_9 2025-12-26T18:44:19+00:00 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-05-10T05:54:39+00:00 tb 2025-05-10T05:54:39+00:00 urn:sha1:41e8f99dd1625a9f0c80ce9d4383e95b18e85709 ok jsing 2025-01-05T16:07:08+00:00 tb 2025-01-05T16:07:08+00:00 urn:sha1:26c9248a10bd0d95f47397e21bc2f056e53e19c8 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 2024-12-16T06:11:26+00:00 tb 2024-12-16T06:11:26+00:00 urn:sha1:b19d3762a5c9d4830000c9ee4a3b5562f5007ad4 This had an extra dance to allow a NULL output buffer. The plan was to use this in i2o_ECPublicKey() to preserve the behavior of avoiding an allocation if out == NULL. However, when I rewrote the latter I punted on preserving that complication, as it was already batshit crazy enough. Thus, remove said dance and make ec_point_to_octets() cleaner. ok jsing 2024-12-12T10:00:15+00:00 tb 2024-12-12T10:00:15+00:00 urn:sha1:4f38523378d1aec3f012e825f343758e4861f2f4 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. 2024-11-08T02:24:37+00:00 tb 2024-11-08T02:24:37+00:00 urn:sha1:6d179c09913c0a5c5401d9b87ceea55c903a6439 2024-11-02T16:02:01+00:00 tb 2024-11-02T16:02:01+00:00 urn:sha1:a1e4dc991adb7095aeb1a0b53f421f6d94cf8f5f 2024-11-01T05:20:58+00:00 tb 2024-11-01T05:20:58+00:00 urn:sha1:0cb2a2476b758ee5bb2fd68491189400b213a325 EC_POINT_oct2point() is the only API that needs detailed knowledge about this incomplete enum. [Arguably, the setters for the EC_KEY and EC_GROUP member of that type would also need to be able to validate what's being set, but they can't since they can't fail.] Anyway. Add a helper that lets EC_POINT_oct2point() translate that enum to its internal representation at the API boundary and add a check that ensures that we only encode the point at infinity as the point at infinity. ok jsing 2024-10-31T15:42:47+00:00 tb 2024-10-31T15:42:47+00:00 urn:sha1:211987661d8c34699fd344ac1a8a5791d8c5c9bc With the functions living in ec_convert now, the oct makes little sense. And ec_oct_oct2point() was too much for poor jsing to bear. requested by jsing 2024-10-31T15:37:53+00:00 tb 2024-10-31T15:37:53+00:00 urn:sha1:bebe8bdb2de5180072fb5cf327bce41d8398e8cc Both our remaining EC_METHODs use the methods that used to be called ec_GFp_simple_{oct2point,point2oct}() so there's no need for the function pointer indirection. Make the public API call them directly. ok jsing