summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/ec (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* Now that we have C99 initializers, garbage collect some commentstb2023-05-011-299/+299
|
* Rework the curve list to use actual structs instead of a customtb2023-05-011-742/+1530
| | | | | | serialized format. ok jsing
* Drop the now unnecessary and unused field_type from the curve datatb2023-05-011-54/+4
| | | | ok jsing
* Convert EC_CURVE_DATA to C99 initializerstb2023-05-011-51/+192
| | | | | | Also clean up the definition of EC_CURVE_DATA a bit. ok jsing
* Simplify ec_group_new_from_data() furthertb2023-05-011-16/+55
| | | | | | | | | | We have a BN_CTX available, so we may as well use it. This simplifies the cleanup path at the cost of a bit more code in the setup. Also use an extra BIGNUM for the cofactor. Reusing x for this is just silly. If you were really going to avoid extra allocations, this entire function could easily have been written with three BIGNUMs. ok jsing
* Drop some dead codetb2023-05-011-11/+2
| | | | | | | No member of the curve_list[] table has a method set. Thus, curve.meth is always NULL and we never take the EC_GROUP_new(meth) code path. ok jsing
* Remove pointless/wrong .meth = 0 entries from curves_list[]tb2023-05-011-55/+1
|
* Mechanically convert curve_list[] to C99 initializerstb2023-05-011-55/+325
| | | | ok jsing
* Clean up handling of nist_curves[]tb2023-05-011-18/+14
| | | | | | | | There's no point in introducing a typedef only for two sizeof() calls. We might as well use an anonymous struct for this list. Make it const while there, drop some braces and compare strcmp() return value to 0. ok jsing
* Move EC_POINT_{get,set}_Jprojective_coordinates to ec_local.htb2023-04-272-10/+12
|
* Nuke doxygen noisetb2023-04-271-421/+37
|
* Clean up ec.h a little.tb2023-04-261-186/+31
| | | | | The doxygen comments are either obvious or otherwise unhelpful and generally an eye sore. Go read the manpage if the header isn't enough.
* GF2m bites the dust. It won't be missed.tb2023-04-259-3320/+9
|
* Remove prototype of EC_GFp_nist_method()tb2023-04-251-8/+1
|
* Move EC_KEY_{insert,set}_key_method_data() to internal-onlytb2023-04-252-18/+7
|
* Remove the horror show that is bn_nist and ecp_nisttb2023-04-251-177/+0
| | | | | | This code is full of problematic C and is also otherwise of questionable quality. It is far from constant time and jsing informs me it also isn't faster. Good riddance.
* Wire up truncated SHA-2, SHA-3 and related thingstb2023-04-251-2/+7
| | | | from jsing
* Use NULL, not 0 for pointers and use an explicit comparison against NULL.tb2023-04-181-3/+3
|
* Remove prototypes under OPENSSL_NO_EC_NISTP_64_GCC_128tb2023-04-181-18/+1
| | | | | | | The code was deleted a while back, the prototypes remained. We had OPENSSL_NO_EC_NISTP_64_GCC_128 in opensslfeatures.h since forever. discussed with jsing
* Sigh cvs... Also drop OPENSSL_NO_DEPRECATED from ec.htb2023-04-181-3/+1
|
* Mark public bn_nist and ec_nist API for removaltb2023-04-161-1/+3
| | | | | | | | | | | | | The faster nist code is rife with problematic C. While this is generally considered to be a pleonasm nowadays, here it specifically refers to aliasing issues and other flavors of undefined behavior. With compilers and standardization committees becoming seemingly more determined about making C even more unusable than it already is, this code has resulted in miscompilations and generally is a target rich environment for fuzzers to feast on. We're better off without it. Go look while it's still there. It's some of the very worst we have to offer. ok jsing
* Mark EC_KEY_{get,insert}_method_data() for removaltb2023-04-161-1/+5
| | | | | | | This is unused and in the way of some house keeping. Thus it will be relocated to the attic. ok jsing
* 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-1111-491/+553
| | | | | | | | | | | 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@
* Clean up unused BIGNUM.jsing2023-04-111-4/+1
|
* Replace the remaining BN_copy() with bn_copy()tb2023-03-276-70/+70
| | | | ok jsing
* Return the signature length after successful signing operationtb2023-03-151-1/+3
| | | | | | | | | This is required behavior of the EVP_DigestSign() API, but seemingly almost nothing uses this. Well, turns out ldns does. Reported by Stephane. Helpful comments by sthen. ok jsing
* Fix a EC_GROUP_clear_free() that snuck through.jsing2023-03-081-2/+2
| | | | Thanks to Mark Patruck for reporting.
* Fix previous.jsing2023-03-081-5/+5
|
* Always clear EC groups and points on free.jsing2023-03-0810-114/+35
| | | | | | | | | | 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@
* Stop trying to use EC_GFp_nist_method().jsing2023-03-081-76/+20
| | | | | | | | | | | | | | | | | | | | | | | | Currently, if compiled without OPENSSL_BN_ASM_MONT, EC_GROUP_new_curve_GFp() tries to use EC_GFp_nist_method(), falling back to EC_GFp_mont_method() if it is not a NIST curve (if OPENSSL_BN_ASM_MONT is defined we use EC_GFp_mont_method() unconditionally). Now that we have a reasonable non-assembly Montgomery implementation, the performance of EC_GFp_nist_method() is either similar or slower than EC_GFp_mont_method() (the exception being P-521, however if you're using that you're not doing it for performance reasons anyway). The EC_GFp_nist_method() uses rather scary BN NIST code (which would probably already be removed, if not for the BN and EC public APIs), it uses code paths that are currently less constant time, and there is additional overhead in checking to see if the curve is actually supported. Stop trying to use EC_GFp_nist_method() and unconditionally use EC_GFp_mont_method() in all cases. While here, factor out the common setup code and call it from both EC_GROUP_new_curve_GFp() and EC_GROUP_new_curve_GF2m(). ok beck@ tb@
* Remove EC_FLAGS_DEFAULT_OCT.jsing2023-03-086-79/+27
| | | | | | | | | | | | | | The EC code has an amazing array of function pointer hooks, such that a method can hook into almost any operation... and then there is the EC_FLAGS_DEFAULT_OCT flag, which adds a bunch of complex code and #ifdef so you can avoid setting three of those function pointers! Remove EC_FLAGS_DEFAULT_OCT, the now unused flags field from EC_METHOD, along with the various code that was wrapped in EC_FLAGS_DEFAULT_OCT, setting the three function pointers that need to be set in each of the EC_METHODs. ok beck@ tb@
* Call BN_free() instead of BN_clear_free().jsing2023-03-075-22/+22
| | | | | | | BN_clear_free() is a wrapper that calls BN_free() - call BN_free() directly instead. ok tb@
* Fix another return value check for CMS_SharedInfo_encode()tb2023-03-071-2/+2
| | | | This should have been included in a previous diff/commit...
* Move EC_GFp_simple_method() to the bottom of the file.jsing2023-03-071-75/+51
| | | | | | | | Most of the implemeentation functions for EC_GFp_simple_method() are reused by other code, hence they cannot be made static. However, this keeps the pattern consistent. ok tb@
* Use static functions for EC_GF2m_simple_method() implementation.jsing2023-03-072-131/+74
| | | | | | | Move the EC_METHOD to the bottom of the file, which allows implementation functions to become static. Remove unneeded prototypes. ok tb@
* Use static functions for EC_GFp_nist_method() implementation.jsing2023-03-072-63/+53
| | | | | | | Move the EC_METHOD to the bottom of the file, which allows implementation functions to become static. Remove unneeded prototypes. ok tb@
* Use static functions for EC_GFp_mont_method() implementation.jsing2023-03-072-86/+62
| | | | | | | Move the EC_METHOD to the bottom of the file, which allows all implementation functions to become static. Remove unneeded prototypes. ok tb@
* Fix formatting of comments.jsing2023-03-071-14/+27
|
* Consolidate clear code for EC_GFp_mont_method.jsing2023-03-071-23/+18
| | | | | | | Use a fang dangled thing (known as a function) to avoid duplicating the same code in five places. ok tb@
* Fix some return checks in ecdh_cms_encrypt()tb2023-03-061-3/+3
| | | | | | | | | | | | i2d functions return <= 0 on error, so check for that instead of == 0. The issue with CMS_SharedInfo_encode() was found by Niels Dossche. OpenSSL review overlooked that they had turned penclen into a size_t. In principle the issue with i2d_X509_ALGOR() is purely cosmetic. Why do a strange check when there is an idiomatic check? Then again this is CMS... ok jsing
* Remove #ifndef OPENSSL_EC_NISTP_64_GCC_128.jsing2023-03-051-5/+1
| | | | | | This was presumably intended to be OPENSSL_NO_EC_NISTP_64_GCC_128, however generic code has ended up inside the ifdef (and none of the NISTP code or prototypes now remain).
* Remove ec_GFp_nistp.* prototypes.jsing2023-03-051-40/+1
| | | | This code has been deleted, however the prototypes managed to hang around.
* Remove duplicate function prototypes.jsing2023-03-051-8/+1
|
* Mop up ECP_NISTZ256_ASM and OPENSSL_NO_EC_NISTP_64_GCC_128 leftovers.jsing2023-03-042-22/+3
| | | | | This is `unifdef -m -DOPENSSL_NO_EC_NISTP_64_GCC_128 -UECP_NISTZ256_ASM` and some manual tidy up.
* Rename field_data1 and field_data2.jsing2023-03-042-48/+50
| | | | | | | | Rather than pretending that these "generic" variables are used for multiple things, rename them to reflect their actual usage and use appropriate types instead of void *. 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
* Remove unused Elliptic Curve code.jsing2023-01-1410-25329/+0
| | | | | | | | | | | | | For various reasons, the ecp_nistp* and ecp_nistz* code is unused. While ecp_nistp* was being compiled, it is disabled due to OPENSSL_NO_EC_NISTP_64_GCC_128 being defined. On the other hand, ecp_nistz* was not even being built. We will bring in new versions or alternative versions of such code, if we end up enabling it in the future. For now it is just causing complexity (and grep noise) while trying to improve the EC code. Discussed with tb@
* Clean up and simplify EC_KEY handling, mostly from a BN_CTX perspective.jsing2023-01-141-59/+80
| | | | | | | | | If we have a BN_CTX available, make use of it rather than calling BN_new(). Always allocate a new priv_key and pub_key, rather than having complex reuse dances on entry and exit. Add missing BN_CTX_start()/BN_CTX_end() calls. ok tb@