summaryrefslogtreecommitdiff
path: root/src/lib (follow)
Commit message (Collapse)AuthorAgeFilesLines
* const correct first argument of pitem_new()tb2025-05-042-4/+4
| | | | Makes upcoming changes in regress less ugly.
* Remove the X9.62 prime239v{1,2,3} curvestb2025-05-041-179/+1
| | | | | | | | | | | | | While RFC 3279 allows these curves for use in X.509 certificates (*), no one actually does this. Certs using these curves cannot be used for TLS and the curves aren't accepted by FIPS either. codesearch shows no actual uses of these curves, only their OIDs are listed. At this point these have become useless historical baggage. ok jsing (*) Of the 27 curves listed in RFC 3279 the only one that seems to have seen actual use in certificates is P-256.
* Move P-256 where it belongstb2025-05-041-67/+67
| | | | ok jsing
* Fix typo in curve comment: P224r2 -> P224t1tb2025-05-031-2/+2
|
* CTASSERT that internal pub/priv keys match the sizes exposed in mlkem.htb2025-05-032-2/+10
| | | | | | | This will need reworking (especially deduplicating) anyway, but it doesn't hurt now. From Kenjiro Nakayama
* More space around .Dl + a typo on toptb2025-05-012-5/+11
|
* lhash: add missing spaces before assignment operatortb2025-05-011-4/+4
|
* tlsext: stop sending SNI before ALPN in clientstb2025-04-301-24/+1
| | | | | | | | | | | All supported releases of LibreSSL ensure that the corresponding callbacks are called in a predefined order rather than honoring the order in which a client sends its extensions. Therefore the ALPN callback for apache-httpd's virtual host setups can rely on SNI information being available and we no longer need to work around this on hte client side. Cuts the amount of code needed for tlsext randomization in half. ok jsing
* EC_GROUP_check.3: rephrase a sentence to avoid a word repetitiontb2025-04-281-4/+4
|
* EC_GROUP_new_by_curve_name.3: escape a - in code.tb2025-04-281-3/+3
|
* EC_POINT_point2oct: remove in_ prefix in RETURN VALUEStb2025-04-261-5/+5
|
* EC_GROUP_new_curve_GFp: some fixes in the RETURN VALUE sectiontb2025-04-261-9/+12
|
* Fix markup for EC_GROUP_set_point_conversion_formtb2025-04-261-4/+5
|
* Fix up a few dangling referencestb2025-04-254-13/+12
|
* Rework EC documentationtb2025-04-2513-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 admonitiontb2025-04-251-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.jsing2025-04-251-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.jsing2025-04-251-13/+5
| | | | ok tb@
* Use the OPENSSL_SMALL_FOOTPRINT code in gcm_init_4bit().jsing2025-04-251-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.jsing2025-04-232-44/+2
| | | | ok beck@ tb@
* Rewrite gcm_gmult_1bit() to avoid sizeof(long) hacks.jsing2025-04-231-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.jsing2025-04-231-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.jsing2025-04-235-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.jsing2025-04-221-3/+1
|
* Use OPENSSL_assert() instead of assert().jsing2025-04-221-10/+6
| | | | | | While here, tidy up the assignment of n and test directly. ok tb@
* Remove now unused PUTU32 macros from modes_local.h.jsing2025-04-221-3/+1
| | | | ok tb@
* Use crypto_load_be32toh()/crypto_store_htobe32() instead of GETU32/PUTU32.jsing2025-04-221-4/+6
| | | | ok tb@
* Mop up unused MODES_DEBUG.jsing2025-04-217-49/+7
|
* Fix another #include that was hiding.jsing2025-04-211-2/+2
|
* Tidy includes.jsing2025-04-216-14/+25
|
* Use standard integer types rather than custom typedefs.jsing2025-04-212-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.jsing2025-04-202-56/+47
| | | | | | This is where almost all of the public functions exist. ok beck@ tb@
* Fix indentation and line wrapping.jsing2025-04-181-17/+15
|
* Remove BS-AES and VP-AES from EVP.jsing2025-04-183-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 ssltb2025-04-181-3/+3
|
* Remove two unused defines, update standard referencetb2025-04-181-7/+3
| | | | ok jsing
* Use 'ctx' for sha3_ctx variables, rather than the less readable 'c'.jsing2025-04-182-36/+36
| | | | ok tb@
* Fix annoying whitespacetb2025-04-184-52/+52
|
* Pull casts from void * to uint8_t * up to variables, rather than inline.jsing2025-04-181-9/+11
| | | | ok tb@
* Use two temporary variables in sha3_keccakf(), rather than reusing bc[0].jsing2025-04-181-8/+8
| | | | ok tb@
* Use crypto_rol_u64() instead of a separate ROTL64 define.jsing2025-04-181-5/+4
| | | | ok tb@
* Use hyphenated spelling for the SHAs except for the APItb2025-04-1712-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.
* 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@
* Plug a memory leak in x509_name_encode()tb2025-03-201-2/+4
| | | | | | | | | This is nearly identical to a leak fixed by miod 10 years ago in x509_name_canon() but was missed in r1.30. This entire file needs a metric ton of bleach, but my head currently spins too much for tackling this, so go with the cheap one-liner. From Niels Dossche
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-08-04 02:11:55 +0000