summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/ec/ec_lib.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* Provide and use ec_group_get_field_type()tb2024-10-221-3/+11
| | | | | | | | | All internal uses of EC_METHOD_get_field_type() and EC_GROUP_method_of() are chained together. Implement this as a single API call that takes a group and use it throughout. Gets rid of another eyesore in this part of the tree. Not that there will be a shortage of eyesores anytime soon... ok jsing
* EC_GROUP_check(): zap useless commentstb2024-10-191-4/+3
|
* Move EC_GROUP_check() to ec_lib.ctb2024-10-191-1/+56
| | | | EC_GROUP_check() is quite simple. It doesn't need to use its own file.
* Move EC_GROUP_new_curve_GFp() into ec_lib.ctb2024-10-181-1/+22
| | | | Another single-function file goes away.
* Unindent error check in EC_GROUP_set_generator()tb2024-10-151-5/+5
|
* Provide EC_GROUP_get0_cofactor() for internal usetb2024-10-151-1/+7
| | | | | | While this is public API in OpenSSL, there are no plans to expose it. ok jsing
* One empty line is enoughtb2024-04-231-18/+1
|
* Hide deprecated functions in ec.hbeck2024-04-101-1/+9
| | | | | | use LCRYPTO_UNUSED and remove the LIBRESSL_INTERNAL guard ok tb@
* EC_POINT_is_on_curve() error is -1, not 0.tb2023-07-251-2/+2
| | | | ok miod
* Unbreak the namespace build after a broken mk.conf and tool misfire hadbeck2023-07-071-9/+1
| | | | | | | | me aliasing symbols not in the headers I was procesing. This unbreaks the namespace build so it will pass again ok tb@
* Hide symbols in hkdf, evp, err, ecdsa, and ecbeck2023-07-071-1/+55
| | | | | | (part 2 of commit) ok jsing@
* Provide internal-only EC_GROUP_get0_order()tb2023-07-031-2/+7
| | | | ok jsing
* Remove EC_EXTRA_DATAtb2023-06-251-153/+1
| | | | | | | | | | | With the ecdh_check() and ecdsa_check() abominations gone, we can finally get rid of EC_EXTRA_DATA and EC_KEY_{get,insert}_key_method_data(). The EC_EX_DATA_*() handlers, (which fortunately have always had "'package' level visibility") join the ride to the great bit bucket in the sky. Thanks to op for making this possible. ok jsing
* Remove precompute_mult/have_precompute_mult from EC_METHOD.jsing2023-06-241-23/+3
| | | | | | | These are no longer in use - stub EC_GROUP_precompute_mult() and EC_GROUP_have_precompute_mult() to match their existing behaviour. ok tb@
* Mop up EC_GROUP precomp machinery.jsing2023-06-241-19/+1
| | | | | | | | | | | Since there are now no EC implementations that perform pre-computation at the EC_GROUP level, remove all of the precomp machinery, including the extra_data EC_GROUP member. The ec_wNAF_mul() code is horrific - simply cut out the precomp code, rather than trying to rewrite it (that's a project for another day). ok tb@
* Consolidate elliptic curve cofactor handlingtb2023-06-201-49/+41
| | | | | | | | | | | | | The various checks of the cofactor to be set in EC_GROUP_set_generator() are a bit all over the place. Move them into a single function and clean things up a little. Instead of calculating directly with the cofactor member of the group, use a temporary variable and copy this variable only if all tests passed. In cryptographic contexts the cofactor almost always fits if not into a single byte then into a word, so copying is cheap. Also streamline the computations a bit and remove some binary curve contortions. ok jsing
* Rewrite ECParameters_dup()tb2023-05-041-7/+12
| | | | | | | This should leak slightly less than the direct expansion of ASN1_dup_of(). Use freezero() since the DER could contain a private key. ok jsing
* GF2m bites the dust. It won't be missed.tb2023-04-251-35/+1
|
* ec_lib.c: fix a few NULL misspellingstb2023-04-131-6/+6
|
* Fix various early return issues spotted by coveritytb2023-04-131-13/+13
| | | | | | | A large mechanical diff led to sloppy review and gave coverity an opportunity to be right for once. First time in a good many weeks. same diff/ok jsing
* Handle BN_CTX at the EC API boundary.jsing2023-04-111-114/+338
| | | | | | | | | | | The EC API allows callers to optionally pass in a BN_CTX, which means that any code needing a BN_CTX has to check if one was provided, allocate one if not, then free it again. Rather than doing this dance throughout the EC code, handle the BN_CTX existance at the EC API boundary. This means that lower level implementation code can simply assume that the BN_CTX is available. ok tb@
* Replace the remaining BN_copy() with bn_copy()tb2023-03-271-8/+8
| | | | ok jsing
* Fix previous.jsing2023-03-081-5/+5
|
* Always clear EC groups and points on free.jsing2023-03-081-40/+13
| | | | | | | | | | Rather than sometimes clearing, turn the free functions into ones that always clear (as we've done elsewhere). Turn the EC_GROUP_clear_free() and EC_POINT_clear_free() functions into wrappers that call the *_free() version. Do similar for the EC_METHOD implementations, removing the group_clear_finish() and point_clear_finish() hooks in the process. ok tb@
* Call BN_free() instead of BN_clear_free().jsing2023-03-071-3/+3
| | | | | | | BN_clear_free() is a wrapper that calls BN_free() - call BN_free() directly instead. ok tb@
* libcrypto/ec: another missing point-on-curve checktb2023-02-071-3/+9
| | | | | | | | | | Unlike in the affine/compressed/... cases, when setting projective coordinates of an elliptic curve point, there is no check whether the point is actually on the curve. Pointed out by Guido Vranken ok beck miod
* Make internal header file names consistenttb2022-11-261-3/+3
| | | | | | | | | | | | | | | | Libcrypto currently has a mess of *_lcl.h, *_locl.h, and *_local.h names used for internal headers. Move all these headers we inherited from OpenSSL to *_local.h, reserving the name *_internal.h for our own code. Similarly, move dtls_locl.h and ssl_locl.h to dtls_local and ssl_local.h. constant_time_locl.h is moved to constant_time.h since it's special. Adjust all .c files in libcrypto, libssl and regress. The diff is mechanical with the exception of tls13_quic.c, where #include <ssl_locl.h> was fixed manually. discussed with jsing, no objection bcook
* Fix an annoying quirk in the EC codetb2022-11-191-30/+30
| | | | | | Dealing with elliptic curves makes some people think that it would be kind of neat to multiply types with variable names. Sometimes. Only in function definitions.
* Avoid infinite loop for custom curves of order 1tb2022-04-071-3/+3
| | | | | | | | | | | | If a private key encoded with EC parameters happens to have order 1 and is used for ECDSA signatures, this causes an infinite loop since a random integer x in the interval [0,1) will be 0, so do ... while (x == 0); will loop indefinitely. Found and reported with a reproducer by Hanno Boeck. Helpful comments and analysis from David Benjamin. ok beck jsing
* Bound cofactor in EC_GROUP_set_generator()tb2022-03-291-1/+7
| | | | | | | | | | | | | | | | | | Instead of bounding only bounding the group order, also bound the cofactor using Hasse's theorem. This could probably be made a lot tighter since all curves of cryptographic interest have small cofactors, but for now this is good enough. A timeout found by oss-fuzz creates a "group" with insane parameters over a 40-bit field: the order is 14464, and the cofactor has 4196223 bits (which is obviously impossible by Hasse's theorem). These led to running an expensive loop in ec_GFp_simple_mul_ct() millions of times. Fixes oss-fuzz #46056 Diagnosed and fix joint with jsing ok inoguchi jsing (previous version)
* Do not zero cofactor on ec_guess_cofactor() successtb2022-03-291-2/+6
| | | | | | | The cofactor we tried to calculate should only be zeroed if we failed to compute it. ok inoguchi jsing
* Zap trailing whitespacetb2022-03-291-46/+46
|
* Default to using named curve parameter encodingtb2021-09-121-2/+2
| | | | | | | | | | | | | | | | | | The pre-OpenSSL 1.1.0 default was to use explicit curve parameter encoding. Most applications want to use named curve parameter encoding and have to opt into this explicitly. Stephen Henson changed this default in OpenSSL commit 86f300d3 6 years ago and provided a new OPENSSL_EC_EXPLICIT_CURVE define to opt back into the old default. According to Debian's codesearch, no application currently does this, which indicates that we currently have a bad default. In the future it is more likely that applications expect the new default, so we follow OpenSSL to avoid problems. Prompted by schwarze who noted that OPENSSL_EC_EXPLICIT_CURVE is missing. ok beck inoguchi jsing
* Prepare to provide EC_GROUP_order_bits()tb2021-09-081-1/+17
| | | | ok jsing
* Compare function pointers against NULL, not 0.tb2021-04-201-3/+3
| | | | ok jsing
* Provide EC_POINT_{g,s}et_Jprojective_coordinates for internal usetb2021-04-201-11/+25
| | | | ok jsing
* Compare function pointers against NULL, not 0.tb2021-04-201-3/+3
| | | | ok jsing
* Prepare to provide EC_POINT_{g,s}et_affine_coordinatestb2021-04-201-32/+23
| | | | | | Similar to part of OpenSSL commit 8e3cced75fb5fee5da59ebef9605d403a999391b ok jsing
* Compare function pointers against NULL, not 0.tb2021-04-201-3/+3
| | | | ok jsing
* Prepare to provide EC_GROUP_{get,set}_curve(3)tb2021-04-201-26/+29
| | | | | | | | | | | | | There are numerous functions in ec/ that exist with _GF2m and _GFp variants for no good reason. The code of both variants is the same. The EC_METHODs contain a pointer to the appropriate version. This commit hides the _GF2m and _GFp variants from internal use and provides versions that work for both curve types. These will be made public in an upcoming library bump. Similar to part of OpenSSL commit 8e3cced75fb5fee5da59ebef9605d403a999391b ok jsing
* Move point-on-curve check to set_affine_coordinatestb2020-12-041-3/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bad API design makes it possible to set an EC_KEY public key to a point not on the curve. As a consequence, it was possible to have bogus ECDSA signatures validated. In practice, all software uses either EC_POINT_oct2point*() to unmarshal public keys or issues a call to EC_KEY_check_key() after setting it. This way, a point on curve check is performed and the problem is mitigated. In OpenSSL commit 1e2012b7ff4a5f12273446b281775faa5c8a1858, Emilia Kasper moved the point-on-curve check from EC_POINT_oct2point to EC_POINT_set_affine_coordinates_*, which results in more checking. In addition to this commit, we also check in the currently unused codepath of a user set callback for setting compressed coordinates, just in case this will be used at some point in the future. The documentation of EC_KEY_check_key() is very vague on what it checks and when checks are needed. It could certainly be improved a lot. It's also strange that EC_KEY_set_key() performs no checks, while EC_KEY_set_public_key_affine_coordinates() implicitly calls EC_KEY_check_key(). It's a mess. Issue found and reported by Guido Vranken who also tested an earlier version of this fix. ok jsing
* If a NULL or zero cofactor is passed to EC_GROUP_set_generator(),tb2019-09-291-9/+109
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | try to compute it using Hasse's bound. This works as long as the cofactor is small enough. Port of Brumley's fix for CVE-2019-1547 in OpenSSL 1.1.1 (old license) tests & ok inoguchi input & ok jsing commit 30c22fa8b1d840036b8e203585738df62a03cec8 Author: Billy Brumley <bbrumley@gmail.com> Date: Thu Sep 5 21:25:37 2019 +0300 [crypto/ec] for ECC parameters with NULL or zero cofactor, compute it The cofactor argument to EC_GROUP_set_generator is optional, and SCA mitigations for ECC currently use it. So the library currently falls back to very old SCA-vulnerable code if the cofactor is not present. This PR allows EC_GROUP_set_generator to compute the cofactor for all curves of cryptographic interest. Steering scalar multiplication to more SCA-robust code. This issue affects persisted private keys in explicit parameter form, where the (optional) cofactor field is zero or absent. It also affects curves not built-in to the library, but constructed programatically with explicit parameters, then calling EC_GROUP_set_generator with a nonsensical value (NULL, zero). The very old scalar multiplication code is known to be vulnerable to local uarch attacks, outside of the OpenSSL threat model. New results suggest the code path is also vulnerable to traditional wall clock timing attacks. CVE-2019-1547 Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com> (Merged from https://github.com/openssl/openssl/pull/9781)
* unrevert the use of bn_rand_interval().tb2018-11-061-2/+2
| | | | ok beck jsing
* Implement coordinate blinding for EC_POINT.tb2018-11-051-1/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Based on OpenSSL commit 875ba8b21ecc65ad9a6bdc66971e50 by Billy Brumley, Sohaib ul Hassan and Nicola Tuveri. ok beck jsing commit 875ba8b21ecc65ad9a6bdc66971e50461660fcbb Author: Sohaib ul Hassan <soh.19.hassan@gmail.com> Date: Sat Jun 16 17:07:40 2018 +0300 Implement coordinate blinding for EC_POINT This commit implements coordinate blinding, i.e., it randomizes the representative of an elliptic curve point in its equivalence class, for prime curves implemented through EC_GFp_simple_method, EC_GFp_mont_method, and EC_GFp_nist_method. This commit is derived from the patch https://marc.info/?l=openssl-dev&m=131194808413635 by Billy Brumley. Coordinate blinding is a generally useful side-channel countermeasure and is (mostly) free. The function itself takes a few field multiplicationss, but is usually only necessary at the beginning of a scalar multiplication (as implemented in the patch). When used this way, it makes the values that variables take (i.e., field elements in an algorithm state) unpredictable. For instance, this mitigates chosen EC point side-channel attacks for settings such as ECDH and EC private key decryption, for the aforementioned curves. For EC_METHODs using different coordinate representations this commit does nothing, but the corresponding coordinate blinding function can be easily added in the future to extend these changes to such curves. Co-authored-by: Nicola Tuveri <nic.tuv@gmail.com> Co-authored-by: Billy Brumley <bbrumley@gmail.com> Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com> Reviewed-by: Andy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/6526)
* Recommit Billy Brumley's ECC constant time patch with a fix for sparc64tb2018-07-161-31/+68
| | | | | | | from Nicola Tuveri (who spotted the omission of ecp_nist.c from the PR). discussed with jsing tested by jsg
* recommit label indentation part of the backout; clearly unrelated to thetb2018-07-151-2/+2
| | | | breakage.
* back out ecc constant time changesjsg2018-07-151-69/+32
| | | | | | | | after the constant time commits various regress tests started failing on sparc64 ssh t9, libcrypto ec ecdh ecdsa and trying to ssh out resulted in 'invalid elliptic curve value' ok tb@
* Indent labels by a space so they don't obliterate function names in diffs.tb2018-07-101-2/+2
|
* ECC constant time scalar multiplication support. First step in overhaulingtb2018-07-101-31/+68
| | | | | | | | | | | the EC module. From Billy Brumley and his team, via https://github.com/libressl-portable/openbsd/pull/94 With tweaks from jsing and me. ok jsing
* use freezero() instead of memset/explicit_bzero + free. Substantiallyderaadt2017-05-021-9/+4
| | | | | | | | | | reduces conditional logic (-218, +82). MOD_EXP_CTIME_MIN_CACHE_LINE_WIDTH cache alignment calculation bn/bn_exp.c wasn'tt quite right. Two other tricky bits with ASN1_STRING_FLAG_NDEF and BN_FLG_STATIC_DATA where the condition cannot be collapsed completely. Passes regress. ok beck
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-04-02 02:38:50 +0000