summaryrefslogtreecommitdiff
path: root/src/lib (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* remove some "intentionally undocumented" comments regarding stuffschwarze2025-06-089-37/+27
| | | | | that no longer exists, and add .Lb; OK tb@
* add the missing .In line and add .Lb libcrypto ; OK tb@schwarze2025-06-082-4/+8
|
* Remove ${MULTIPLE_OF_EIGHT}_BIT*tb2025-06-0813-144/+0
| | | | | | | | These are unused internally and very few things look at them, none of which should really matter to us, except possibly free pascal on Windows. sizeof has been available since forever... ok jsing
* More code clean up.jsing2025-06-081-10/+9
| | | | | Fix some things that got missed in the last pass - the majority is use of post-increment rather than unnecessary pre-increment.
* Remove more mess related to arm assembly.jsing2025-06-081-23/+1
|
* Garbage collect DES_PTRtb2025-06-0813-78/+0
| | | | pointed out by/ok jsing
* Remove DES_RISC*tb2025-06-0813-715/+0
| | | | | | | | | | | | | | | codesearch.debian.net only shows some legacy openssl patches plus binkd (a FidoNet mailer) as sole potential user. net-snmp and a strongswan DES plugin bundle some opt-in libdes/openssl legacy things. If this should break any of this, I don't think we need to care. If you're really going to use DES you can also use non bleeding edge libressl. We can remove the big 'default values' block because one of DES_RISC1, DES_RISC2, DES_UNROLL is always defined (you can ignore DES_PTR for this), so this is dead support code for mostly dead platforms. ok kenjiro
* Trim trailing whitespacetb2025-06-071-8/+8
|
* Spelling, discussed with jsingtb2025-06-071-1/+1
|
* tls13_ctx_new(): fix calloc() incantationtb2025-06-071-2/+2
| | | | | | Switch argument order and use sizeof(*ctx) rather than sizeof(struct ...). ok jsg
* Fix weird calloc() argument ordertb2025-06-071-5/+5
| | | | ok jsg
* do_PVK_body: Unconditionally free enctmptb2025-06-071-3/+3
| | | | | | | | | | enctmp is only allocated if saltlen > 0, so there is no harm in checking for that, but it's also pointless. Unconfuses smatch who thinks there might be a memory leak: pem/pvkfmt.c:808 do_PVK_body() warn: possible memory leak of 'enctmp' found by jsg
* Fix smatch warning in asn1_primitive_print()tb2025-06-071-2/+2
| | | | | | | | Remove unnecessary and inconsistent NULL check for 'it', which the only caller, asn1_item_print_ctx(), already dereferenced. found by jsg ok kenjiro
* crypto_ex_data: fix allocation size of classes_newtb2025-06-071-2/+2
| | | | | | | | | classes_new is an array of pointers to struct crypto_ex_data, not an array of struct crypto_ex_data_index, so this overallocated by 240 or 480 bytes on ILP32 or LP64, respectively. found by jsg using smatch ok jsing
* Fix EVP_DecryptFinal() for CCM cipherstb2025-06-061-5/+10
| | | | | | | | | | | | | There is an old trap that you must not call EVP_*Final() when using AES-CCM. While encrypting this happens to be a noop and succeeds, but when decrypting, the call fails. This behavior changed in OpenSSL and BoringSSL, making the trap even worse since we now fail when the others succeed. This is an adaptation of OpenSSL commit 197421b1 to fix this. See also https://github.com/sfackler/rust-openssl/pull/1805#issuecomment-2734788336 ok beck kenjiro
* pkcs7.h: drop two spaces before a tabtb2025-06-051-3/+3
|
* Rename the header guard of des.h with HEADER_DES_Htb2025-06-0514-16/+16
| | | | | | libdes is dead, Jim. Only its successors continue to haunt us. discussed with jsing
* Remove preprocessor branching on HEADER_DES_Htb2025-06-0513-13/+13
| | | | | | | | This was the header guard for des_old.h introduced in 2002 and removed in 2014. The header guard for des.h is HEADER_NEW_DES_H for the sake of inconsistency (ostensibly due to backward compat concerns with libdes). ok jsing
* opensslconf.h: remove md2 leftoverstb2025-06-0513-52/+0
| | | | | | | md2.h left on Apr 15, 2014, along with jpake and seed. In particular, HEADER_MD2_H is never defined. These bits have been dead ever since. ok jsing
* libtls: abort handshake on no ALPN protcol overlaptb2025-06-041-2/+2
| | | | | | | | | | | RFC 7301, section 3.2: In the event that the server supports no protocols that the client advertises, then the server SHALL respond with a fatal "no_application_protocol" alert. This change makes tlsext_alpn_server_process() send the alert rather than pretending no callback was present. ok jsing
* Revert 1.144 of lib/libc/stdlib/malloc.3. It was changed by accidentyasuoka2025-06-041-12/+3
| | | | by my previous commit.
* Again. Make exit(), fclose(), fflush(), and freopen() comply withyasuoka2025-06-032-9/+17
| | | | | | | | | | | | | POSIX-2008 requirements for setting the underlying file position when flushing read-mode streams, and make an fseek()-after-fflush() not change the underlying file position. This commit fixes some minor problems of the previous. previous diff from guenther Much testing, review, assistence form tb@ ok tb@ millert@ for the previous ok asou
* Use timingsafe_memcmp when comparing authenticatorskenjiro2025-06-033-9/+9
| | | | | | | | | | | Replace memcmp() with timingsafe_memcmp() for authentication tag comparison in AES-CCM, GCM, PKCS12 and AES key unwrap code paths to ensure constant-time behavior and avoid potential timing side channels. This aligns with OpenSSL 1e4a355. ok tb@
* bn_gcd: fix wacky indentation found by smatchtb2025-06-021-3/+5
| | | | via/ok jsg
* correct indentation, no functional changejsg2025-06-028-25/+28
| | | | found with smatch, ok tb@
* Inline EVP_CIPHER_[gs]et_asn1_iv() in their last callerstb2025-06-021-27/+15
| | | | ok kenjiro
* Fix resource leaks in ec_points_make_affine()tb2025-06-011-1/+4
| | | | | | Add missing BN_CTX_end() and free prod_Z. CID 552848 (for prod_Z)
* zap weird empty added to tls1_ec_nid2group_id() in previoustb2025-05-311-2/+1
|
* Plug leak of bm->buf->datatb2025-05-311-1/+2
| | | | | BIO_new(BIO_s_mem()) now allocates this pointer, so we need to free it before assigning to it.
* Delete bad advice about abusing malloc_options = "X" as a productionschwarze2025-05-271-12/+3
| | | | | | | | | | | | | | | | feature to terminate the program when out of memory. Application code should always handle failure of library functions properly. So if you want your program to terminate, write something like | p = malloc(...); | if (p == NULL) | err(1, NULL); and don't abuse malloc_options. Direction suggested by otto@ after anton@ pointed out that this very old text still used an outdated data type for malloc_options and potentially failed to define its value at compile time. OK otto@
* Make EVP_CIPHER_[gs]et_asn1_iv() local to evp_ciphertb2025-05-279-153/+174
| | | | | | | | | | | | | These formerly public functions have only ever been called from EVP_CIPHER_asn1_to_param() and EVP_CPIHER_param_to_asn1(), either directly if the EVP_CIPH_FLAG_DEFAULT_ASN1 flag is set, or indirectly when set as the .[gs]et_asn1_parameters() method of the EVP_CIPHER. This commit removes their use in .[gs]et_asn1_parameters() dating back to long before the EVP_CIPH_FLAG_DEFAULT_ASN1 was introduced in 2010. This way the only remaining consumer of .[gs]et_asn1_parameters() is RC2. ok jsing
* GOST has left the buildingtb2025-05-261-2/+2
| | | | (comment tweak, no code change)
* Merge AES-IGE into aes.c.jsing2025-05-253-121/+66
|
* Simplify AES-IGE and remove code with implementation defined behaviour.jsing2025-05-251-117/+40
| | | | | | | | | Remove the UNALIGNED_MEMOPS_ARE_FAST from AES-IGE, which can result in implementation defined behaviour on i386/amd64. While we could keep this purely for aligned inputs and outputs, it's probably not that important and can be redone in a simpler form later if we want to do so. ok tb@
* Remove bogus alias.jsing2025-05-251-2/+1
|
* Merge RC2 into a single file.jsing2025-05-256-548/+301
| | | | Discussed with tb@
* Provide an EC method that uses homogeneous projective coordinates.jsing2025-05-253-2/+870
| | | | | | | | | | | | | | This makes use of EC_FIELD_ELEMENT to perform fixed width constant time operations. Addition and doubling of points makes use of the formulas from "Complete addition formulas for prime order elliptic curves" (https://eprint.iacr.org/2015/1060). These are complete and operate in constant time. Further work will continue in tree. ok tb@
* Implement EC field element operations.jsing2025-05-255-31/+299
| | | | | | | | | | Provide EC_FIELD_ELEMENT and EC_FIELD_MODULUS, which allow for operations on fixed width fields in constant time. These can in turn be used to implement Elliptic Curve cryptography for prime fields, without needing to use BN. This will improve the code, reduces timing leaks and enable further optimisation. ok beck@ tb@
* Provide bn_mod_{add,sub,mul}_words().jsing2025-05-254-5/+94
| | | | | | | These implement constant time modular addition, subtraction and multiplication in the Montegomery domain. ok tb@
* Fix previous.jsing2025-05-253-72/+6
|
* Provide additional variants of bn_add_words()/bn_sub_words().jsing2025-05-253-6/+190
| | | | | | | | | | | | | | | | Move bn_add_words() and bn_sub_words() from bn_add.c to bn_add_sub.c. These have effectively been replaced in the previous rewrites. Remove the asserts - if bad lengths are passed the results will be incorrect and things will fail (these should use size_t instead of int, but that is a problem for another day). Provide bn_sub_words_borrow(), which computes a subtraction but only returns the resulting borrow. Provide bn_add_words_masked() and bn_sub_words_masked(), which perform an masked addition or subtraction. These can also be used to implement constant time addition and subtraction, especially for reduction. ok beck@ tb@
* Fix handling of different length inputs in bn_sub().jsing2025-05-251-3/+3
| | | | | | | | | In the diff_len < 0 case, it incorrectly uses 0 - b[0], which mishandles the borrow - fix this by using bn_subw_subw(). Do the same in the diff_len > 0 case for consistency. Note that this is never currently reached since BN_usub() requires a >= b. ok beck@ tb@
* Create bm->buf from the start to avoid arithmetic on NULLtb2025-05-241-1/+7
| | | | | | | | | This is a different way of avoiding the pointer arithmetic on NULL and avoids test breakage in pyca/cryptography. This is also a gross hack that penalizes existing callers of BIO_s_mem(), but this is rarely called in a hot loop and if so that will most likely be a test. ok kenjiro joshua jsing
* Revert "bio_mem: avoid pointer arithmetic on NULL"tb2025-05-241-4/+2
| | | | This causes a test failure in pyca/cryptography.
* explain more precisely how to initialize malloc_options;schwarze2025-05-241-4/+12
| | | | OK deraadt@
* Provide method specific functions for EC POINT infinity.jsing2025-05-243-10/+27
| | | | | | | | Provide method specific functions for EC_POINT_set_to_infinity() and EC_POINT_is_at_infinity(). These are not always the same thing and will depend on the coordinate system in use. ok beck@ tb@
* Mop up ghash arm assembly remnants.jsing2025-05-241-18/+1
|
* Provide openssl_init_crypto_constructor() and invoke via a constructor.jsing2025-05-241-3/+14
| | | | | | | | | | | | | | There are a very large number of entry points to libcrypto, which means it is easy to run code prior to OPENSSL_init_crypto() being invoked. This means that CPU capability detection will not have been run, leading to poor choices with regards to the use of accelerated implementations. Now that our CPU capability detection code has been cleaned up and is safe, provide an openssl_init_crypto_constructor() that runs CPU capability detection and invoke it as a library constructor. This should only be used to invoke code that does not do memory allocation or trigger signals. ok tb@
* Remove remnants of OPENSSL_cpuid_setup().jsing2025-05-243-20/+10
| | | | This is no longer used.
* Disable libcrypto assembly on arm.jsing2025-05-245-257/+2
| | | | | | | | | | | | | | | | | The arm CPU capability detection is uses SIGILL and is unsafe to call from some contexts. Furthermore, this is only useful to detect NEON support, which is then unused on OpenBSD due to __STRICT_ALIGNMENT. Requiring a minimum of ARMv7+VFP+NEON is also not unreasonable. The SHA-1, SHA-256 and SHA-512 (non-NEON) C code performs within ~5% of the assembly, as does RSA when using the C based Montgomery multiplication. The C versions of AES and GHASH code are around ~40-50% of the assembly, howeer if you care about performance you really want to use Chacha20Poly1305 on this platform. This will enable further clean up to proceed. ok joshua@ kinjiro@ tb@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-08-08 10:34:21 +0000