A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=OPENBSD_7_9_BASE 2025-06-08T22:40:31+00:00 2025-06-08T22:40:31+00:00 schwarze 2025-06-08T22:40:31+00:00 urn:sha1:8be86af02fed1bda350c8dd14ee064cb66e3b0f5 2025-04-25T19:57:12+00:00 tb 2025-04-25T19:57:12+00:00 urn:sha1:60904c983d054a3655c2d3ac38828e2b8c9cc067 This replaces the giant, poor quality and outdated EC_GROUP_copy.3, EC_GROUP_new.3, and EC_POINT_new.3 manuals with seven new manuals written from scratch. * EC_GROUP_new_by_curve_name() is the entry point for builtin curves, * EC_GROUP_new_curve_GFp() describes lower level API that should not usually be needed apart from a handful of accessors. * EC_GROUP_check() contains two functions that applications should not need because either you know for certain something is an elliptic curve (so these checks are pointless) or you should not use it. * EC_GROUP_get_curve_name() describes some low level ASN.1 footguns and corresponding getters. * EC_POINT_new() contains the simple EC_POINT allocation and freeing API * EC_POINT_get_affine_coordinates() contains the coordinate accessors * EC_POINT_point2oct() is about encoding elliptic curve points While all this is quite far from perfect, the diff is getting too big and it will be easier to improve this in tree. It is definitely more repetitive than I would like it to be. Reviews, tweaks and general feedback are of course welcome. discussed with jsing 2025-03-08T16:38:13+00:00 tb 2025-03-08T16:38:13+00:00 urn:sha1:f9782c9acfdbef308a07a85a3f2b07c5b67a833e 2024-07-14T05:53:09+00:00 jsg 2024-07-14T05:53:09+00:00 urn:sha1:39b957ffe179b43c6210387801d6145efda01bf1 missed in 2022 "remove please from manual pages" commit ok tb@ 2024-02-16T06:09:36+00:00 tb 2024-02-16T06:09:36+00:00 urn:sha1:9b3ff0a344fbe7e11b995d97399bb6e01a81af4d While EC_POINT_set_affine_coordinates() checks that the resulting point is on the elliptic curve, this is only necessary, but not sufficient, to ensure that the point can serve as a valid public key. For example, this does not check for normalized coordinates or exclude that it is zero (the point at infinity). Such checks, and more, are performed by the similarly named EC_KEY_set_public_key_affine_coordinates(). This kind of makes sense from the mathematical standpoint as an elliptic curve point isn't a priori a public key, even if you are not going to use libcrypto for actual mathematics (or anything really) unless you like pain. In a cryptographic library such differences are more of a hazard than a help. This is exacerbated by the fact that EC_KEY_set_public_key() does almost no checking (it only checks that the point's EC_POINT method matches the one of group set of the EC_KEY, which is far from enough). The API expects that you call EC_KEY_check_key() on your own. This is kind of confusing since EC_KEY_set_public_key_affine_coordinates() does that for you. Unfortunately, adding sanity checks to EC_KEY_set_public_key() isn't easy since it's going to penalize those who already check. Caching the result of a check is dangerous and fragile if there are a million ways of fiddling with an EC_KEY. While the elliptic curve code is really bad, its documentation is worse (another thing that applies to OpenSSL in general). Try to help that a little bit by making it more explicit that you are supposed to call EC_KEY_check_key() after using lower-level EC_KEY setters. Also make it clearer that the setters copy the data, they don't take ownership (which isn't obvious from the naming). If OpenSSL 3 got one thing kind of right, it was to deprecate the EC_KEY and EC_POINT APIs. But if you are going to deprecate something, you should either be prepared to remove it or have a reasonable replacement... Found by Guido Vranken using cryptofuzz https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=66667 ok jsing 2023-08-29T10:07:42+00:00 tb 2023-08-29T10:07:42+00:00 urn:sha1:09dcbefdff671a2602d306db8c2ca196ca43a8d7 Except if backward compatibility with older LibreSSL and OpenSSL versions is explicitly needed, ecdsa.h and ecdh.h should no longer be used. They are now trivial wrappers of ec.h. 2023-04-27T09:49:44+00:00 tb 2023-04-27T09:49:44+00:00 urn:sha1:77bee5c59836dda916c5262bc733d4f0bb17f0d8 2020-09-08T03:25:15+00:00 tb 2020-09-08T03:25:15+00:00 urn:sha1:2021e5076ad7ef88d09bb3b8d8e072e73517bbf1 wording from jmc 2019-08-19T13:08:26+00:00 schwarze 2019-08-19T13:08:26+00:00 urn:sha1:1f66f34e043477d6d7971a65f9c450841a22429a feedback and OK tb@ 2019-08-16T16:20:23+00:00 schwarze 2019-08-16T16:20:23+00:00 urn:sha1:2d560066b2645d8a54ff59fd0700550d4f5f474f and mention a trap set by EC_KEY_copy(3)