summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/man/EC_KEY_new.3 (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Rework EC documentationtb3 days1-9/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove EC_GFp_* and EC_METHOD_get_field_type docstb2025-03-081-3/+2
|
* "please refer" -> "refer"jsg2024-07-141-3/+3
| | | | | missed in 2022 "remove please from manual pages" commit ok tb@
* Make it explicit that the EC_KEY setters don't check thingstb2024-02-161-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Replace last ecdh.h and ecdsa.h occurrences with ec.htb2023-08-291-6/+4
| | | | | | 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.
* EC_KEY_{get,insert}_key_method_data() are no longer availabletb2023-04-271-41/+2
|
* Mention that EC_KEY_get0_public_key returns a public key.tb2020-09-081-3/+5
| | | | wording from jmc
* document ECDH_compute_key(3) and ECDH_size(3);schwarze2019-08-191-2/+3
| | | | feedback and OK tb@
* link to the new EC_KEY_METHOD_new(3) pageschwarze2019-08-161-3/+6
| | | | and mention a trap set by EC_KEY_copy(3)
* finish crypto HISTORY; mostly 1.1.0/6.3, but also various other fixesschwarze2018-03-231-5/+2
|
* crypto HISTORY up to 1.0.1; researched from OpenSSL gitschwarze2018-03-231-1/+9
|
* crypto HISTORY up to 1.0.0; researched from OpenSSL gitschwarze2018-03-231-1/+5
|
* crypto HISTORY up to 0.9.8; researched from OpenSSL gitschwarze2018-03-231-2/+29
|
* Merge documentation for {DH,DSA}_get0_{key,pqg}(3),schwarze2018-02-171-3/+4
| | | | | EVP_PKEY_get0_{DH,DSA,RSA}(3), and RSA_{g,s}et0_key(3) that tb@ just provided.
* Distribute the text of ec(3) to the individual EC manuals where it belongs.schwarze2016-12-111-4/+13
| | | | | | Make sure EC_GROUP_new(3) points to all EC manuals and all EC manuals point back to EC_GROUP_new(3), and add some other useful links as well. Change all links to ec(3) to point to EC_GROUP_new(3) instead.
* Delete most references to crypto(3). That page isn't useful enoughschwarze2016-12-061-3/+2
| | | | to be pointed to from random individual pages.
* Add Copyright and license.schwarze2016-11-221-2/+74
| | | | | | | Mention that EC_KEY_free(3) accepts NULL. Merge some auxiliary explanations regarding the effects of EC_KEY encoding flags, lifted from the separate page EC_KEY_get_enc_flags(3) that OpenSSL split off from EC_KEY_new(3).
* various cleanup;jmc2016-11-151-8/+9
|
* spacing between macro args and punctuation;jmc2016-11-061-2/+2
|
* delete prototypes available in other pages and add two missing .Xr linksschwarze2016-11-061-3/+36
|
* first pass; ok schwarzejmc2016-11-061-1/+3
|
* convert DSA and EC manuals from pod to mdocschwarze2016-11-021-0/+411
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-04-29 07:18:07 +0000