summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* EC_GROUP_check.3: rephrase a sentence to avoid a word repetitionHEADmastertb26 hours1-4/+4
|
* EC_GROUP_new_by_curve_name.3: escape a - in code.tb26 hours1-3/+3
|
* c2sp: drop OpenSSL 1.1 and 3.2, add 3.5tb2 days1-2/+2
|
* EC_POINT_point2oct: remove in_ prefix in RETURN VALUEStb3 days1-5/+5
|
* EC_GROUP_new_curve_GFp: some fixes in the RETURN VALUE sectiontb4 days1-9/+12
|
* Fix markup for EC_GROUP_set_point_conversion_formtb4 days1-4/+5
|
* Fix up a few dangling referencestb4 days4-13/+12
|
* Rework EC documentationtb4 days13-1242/+1998
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* BN_new: zap an anachronistic admonitiontb4 days1-4/+2
| | | | | | | | | -This type should be considered opaque and fields should not be modified -or accessed directly. The type has long been opaque and reasonable people will not do things that permit them to access the fields of opaque types directly. Of course, in the vicinity of OpenSSL code and API all sorts of insanity actually exist.
* Restore two #if defined(GHASH) that were incorrectly removed.jsing4 days1-5/+5
| | | | | | | Also condition on defined(GHASH_CHUNK) since this is used within these blocks. This makes the conditionals consistent with other usage. Fixes build with TABLE_BITS == 1.
* Unifdef OPENSSL_SMALL_FOOTPRINT.jsing4 days1-13/+5
| | | | ok tb@
* Use the OPENSSL_SMALL_FOOTPRINT code in gcm_init_4bit().jsing4 days1-32/+2
| | | | | | | | A modern compiler will unroll these loops - LLVM produces identical code (at least on arm64). Drop the manually unrolled version and have code that is more readable and maintainable. ok tb@
* Mop up all of the GETU32/BSWAP4/BSWAP8 macros since they're now unused.jsing6 days2-44/+2
| | | | ok beck@ tb@
* Rewrite gcm_gmult_1bit() to avoid sizeof(long) hacks.jsing6 days1-22/+8
| | | | | | | | | | | We're already using 64 bit variables, so just continue to do so and let the compiler deal with code generation. While here, use unsigned right shifts instead of relying on signed right shifts and implementation-defined behaviour (which the original code did). Feedback from lucas@ ok beck@ tb@
* Fix CRYPTO_gcm128_decrypt() when compiled with TABLE_BITS == 1.jsing6 days1-3/+3
| | | | | | | | | This appears to have been broken since 2013 when OpenSSL commit 3b4be0018b5 landed. This added in_t and out_t variables, but continued to use in and out instead. Yet another reason why untested conditional code is a bad thing. ok beck@ tb@
* Unifdef OPENSSL_SMALL_FOOTPRINT.jsing6 days5-23/+5
| | | | | | | We do not build with OPENSSL_SMALL_FOOTPRINT and it removes more untested code paths. Request by tb@ (and it was already on my TODO list!)
* Mop up OPENSSL_FIPSAPI define.jsing7 days1-3/+1
|
* Use OPENSSL_assert() instead of assert().jsing7 days1-10/+6
| | | | | | While here, tidy up the assignment of n and test directly. ok tb@
* Remove now unused PUTU32 macros from modes_local.h.jsing7 days1-3/+1
| | | | ok tb@
* Use crypto_load_be32toh()/crypto_store_htobe32() instead of GETU32/PUTU32.jsing7 days1-4/+6
| | | | ok tb@
* Mop up unused MODES_DEBUG.jsing8 days7-49/+7
|
* Fix another #include that was hiding.jsing8 days1-2/+2
|
* Tidy includes.jsing8 days6-14/+25
|
* Use standard integer types rather than custom typedefs.jsing8 days2-25/+21
| | | | | | Replace u32 with uint32_t, remove unused u16 and replace u8 with uint8_t. ok tb@
* Move AES public functions from aes_core.c to aes.c.jsing9 days2-56/+47
| | | | | | This is where almost all of the public functions exist. ok beck@ tb@
* Fix x509's -nameopt default and spell an option correctlykn10 days1-4/+4
| | | | Feedback OK tb
* Fix indentation and line wrapping.jsing11 days1-17/+15
|
* Remove BS-AES and VP-AES from EVP.jsing11 days3-137/+9
| | | | | | | | | | | | | | | | | The bitsliced and vector permutation AES implementations were created around 2009, in attempts to speed up AES on Intel hardware. Both require SSSE3 which existed from around 2006. Intel introduced AES-NI in 2008 and a large percentage of Intel/AMD CPUs made in the last 15 years include it. AES-NI is significantly faster and requires less code. Furthermore, the BS-AES and VP-AES implementations are wired directly into EVP (as is AES-NI currently), which means that any consumers of the AES_* API are not able to benefit from acceleration. Removing these greatly simplifies the EVP AES code - if you just happen to have a CPU that supports SSSE3 but not AES-NI, then you'll now use the regular AES assembly implementations instead. ok kettenis@ tb@
* SSL_set_tlsext_host_name: as a setter it cannot take a const ssltb11 days1-3/+3
|
* Remove two unused defines, update standard referencetb11 days1-7/+3
| | | | ok jsing
* Use 'ctx' for sha3_ctx variables, rather than the less readable 'c'.jsing11 days2-36/+36
| | | | ok tb@
* Fix annoying whitespacetb11 days4-52/+52
|
* Pull casts from void * to uint8_t * up to variables, rather than inline.jsing11 days1-9/+11
| | | | ok tb@
* Use two temporary variables in sha3_keccakf(), rather than reusing bc[0].jsing12 days1-8/+8
| | | | ok tb@
* Use crypto_rol_u64() instead of a separate ROTL64 define.jsing12 days1-5/+4
| | | | ok tb@
* Use hyphenated spelling for the SHAs except for the APItb12 days12-41/+42
| | | | | The mix of SHA256 and SHA-256 is jarring, so use FIPS's spelling. Leave HMAC-SHA256 as it is and fix a nearby RIPEMD-160.
* Enable remaining tests with NULL, 0tb2025-04-142-9/+3
| | | | Now that libc is fixed, we can do this also for md5, rmd160 and sha1.
* Link hash regress to buildtb2025-04-141-1/+2
|
* Add some regress coverage for the hashes in libctb2025-04-142-0/+946
| | | | Prompted by a pending diff by claudio
* Update openssl.1 for msie_hack removaltb2025-04-141-21/+4
| | | | ok jmc jsing
* Remove openssl ca -msie_hacktb2025-04-141-31/+2
| | | | | | The nineties called and wanted their garbage back. ok jsing
* parse_test_file()tb2025-04-131-1/+3
| | | | | | gcc 14 needs a hint that ld != NULL beyond the use of ld->data in the previous line. I guess aggressive inlining is becoming too aggressive. What a pile of junk.
* Avoid compiler warning on some OStb2025-04-131-1/+1
| | | | | | | | Some OS declare arc4random() with __attribute__((warn_unused_result)) causing this test to whine. So explicitly ignore the return value. Reported by scheiba in libressl/portable Fixes #1151
* x509_policy: zap an extra stb2025-03-281-2/+2
|
* x509_policy: certificats -> certificatestb2025-03-281-2/+2
|
* typos: us -> is, te -> the (twice)tb2025-03-281-3/+3
|
* typo: primtive -> primitivetb2025-03-282-4/+4
|
* Fix RETURN VALUES for EVP_CIPHER_CTX_ctrl(3)tb2025-03-251-9/+4
| | | | | | | | | | | | | | | The current documentation was clearly incorrect since a return of -1 from the methods is explicitly intercepted and translated to 0. schwarze and I both audited the tree and concluded that only 0 and 1 is possible. OpenSSL 3 broke this API contract and now has explicit return -1 in the convoluted 200-line maze this simple function has become with recent provider improvements. So add a small sentence hinting at that. Nobody will be surprised to read that with OpenSSL's characteristic penchant for needless inconsistency the return value checks in their tree are all over the place and sometimes incorrect. ok schwarze (with two tweaks)
* Explicitly pass group generator to mul_double_nonct() from EC_POINT_mul().jsing2025-03-244-35/+33
| | | | | | | | | | | | | | | | | | EC_POINT_mul() has a complex multi-use interface - there are effectively three different ways it will behave, depending on which arguments are NULL. In the case where we compute g_scalar * generator + p_scalar * point, the mul_double_nonct() function pointer is called, however only g_scalar, p_scalar and point are passed - it is expected that the lower level implementation (in this case ec_wnaf_mul()) will use the generator from the group. Change mul_double_nonct(), ec_mul_double_nonct() and ec_wnaf_mul() so that they take scalar1, point1, scalar2 and point2. This removes all knowledge of g_scalar and the generator from the multiplication code, keeping it limited to EC_POINT_mul(). While here also consistently pass scalar then point, rather than a mix of scalar/point and point/scalar. ok tb@
* Check group generator in EC_POINT_mul().jsing2025-03-241-1/+6
| | | | | | | | | When a non-NULL generator scalar is passed to EC_POINT_mul(), the group's generator will be used in multiplication. Add a check that ensures that the group generator is non-NULL, in order to avoid needing to handle this elsewhere (currently in the lower level point multiplication code). ok tb@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-04-29 19:24:08 +0000