summaryrefslogtreecommitdiff
path: root/src/lib (follow)
Commit message (Collapse)AuthorAgeFilesLines
* 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@
* Crank default salt length of PBE2 to 16 octetstb2025-05-242-4/+13
| | | | | | | | | | FIPS is currently revising their PBKDF2 recommendations and apparently they want to require 16 octets. https://github.com/pyca/cryptography/issues/12949 https://github.com/libressl/portable/issues/1168 ok kenjiro joshua jsing
* Switch the default PBMAC to hmacWithSHA256tb2025-05-241-2/+2
| | | | | | | | | | Using hmacWithSHA1 isn't outrageously bad, but newly generated encrypted password files ought to be using something better. Make it so. https://github.com/pyca/cryptography/issues/12949 https://github.com/libressl/portable/issues/1168 ok joshua
* When commons were deprecated, noone noticed that malloc_options in staticderaadt2025-05-232-7/+10
| | | | | | | | binaries had become unlinkable. Change the libc definition to weak to solve that, and to "const char * const" so that noone will try to set it late. It must be stable before the first malloc() call, which could be before main()... discussion with otto, kettenis, tedu
* Do a clean up pass over the GCM code.jsing2025-05-221-92/+86
| | | | | | | | Rework some logic, add explicit numerical checks, move assignment out of variable declaration and use post-increment/post-decrement unless there is a specific reason to do pre-increment. ok kenjiro@ tb@
* Use timingsafe_memcmp() in CRYPTO_gcm128_finish().jsing2025-05-221-2/+2
| | | | | | When checking the GCM tag, use timingsafe_memcmp() instead of memcmp(). ok tb@
* Simplify SSL_alert_desc_stringtb2025-05-221-67/+2
| | | | | | | | | | SSL_alert_desc_string() is only used by our good old friends M2Crypto and Net::SSLeay. While some of the two-letter combinations can be made sense of without looking at the switch, I guess, this is just a completely useless interface. The same level of uselessness can be acchieved in a single line matching BoringSSL. ok joshua kenjiro
* Reorder some functions.jsing2025-05-211-20/+20
|
* Remove GHASH_CHUNK and size_t related code from GCM encrypt/decrypt.jsing2025-05-211-220/+1
| | | | | | | | This adds significant complexity to the code. On amd64 and aarch64 it results in a minimal slowdown for aligned inputs and a performance improvement for unaligned inputs. ok beck@ joshua@ tb@
* Fix wrapping.jsing2025-05-211-13/+9
|
* Remove now unused AES assembly generation scripts.jsing2025-05-213-5256/+0
|
* Remove more unused code.jsing2025-05-211-95/+1
| | | | Discussed with tb@
* Add NULL checks to HKDF and TLS1-PRF EVP_PKEY cleanup functionskenjiro2025-05-212-2/+8
| | | | | | | | Check if ctx->data is NULL before calling freezero(). Also add HKDF and TLS1-PRF to the EVP_PKEY cleanup regression test, as they no longer crash with this change. ok tb@
* Fix buffer size in MLKEM1024_marshal_public_key()kenjiro2025-05-211-2/+2
| | | | | | | Initialize the output buffer with MLKEM1024_PUBLIC_KEY_BYTES instead of MLKEM768_PUBLIC_KEY_BYTES. ok tb@
* Unbreak GHASH on some architectures setting GHASH_ASMtb2025-05-201-1/+3
| | | | | | | | The last #else branch in CRYPTO_gcm128_init() doesn't initialize the function pointers for gmult/ghash, which results in a segfault when using GCM on architectures taking this branch, notably sparc64. found by and fix from jca
* Simplify err_build_SYS_str_reasonstb2025-05-201-19/+13
| | | | | | | | This is currently done in a rather silly way. Shift the index by 1 and avoid weird pointer dances. Rather than relying on static initialization, use code to obviate a comment. ok beck joshua jsing
* Fix previous - names use underscores and not hyphens.jsing2025-05-201-3/+3
|
* Add ML-KEM768 Hybrid Kems to obj_mac.numbeck2025-05-201-0/+3
| | | | ok tb@, joshua@
* Add ML-KEM768 Hybrid Kems to objects.txtbeck2025-05-201-0/+6
| | | | ok tb@, joshua@
* Don't use the array index as the group_idbeck2025-05-201-51/+97
| | | | | | | | | | | | This is a precursor to adding new group ids for post quantum stuff which are up in the 4000 range, so using the array index as the group id will be silly. Instead we just add the group id to the structure and we walk the list to find it. This should never be a very large list for us, so no need to do anything cuter than linear search for now. ok jsing@, joshua@
* Make MLKEM1024_marshal_private_key consistent with the public_key funcitonsbeck2025-05-202-27/+44
| | | | | | | | Even though this should remain internal, make it the same as the public key marshal function, and make the needed fallout changes in regress. ok kenjiro@, tb@
* Whitespace nits from tbbeck2025-05-201-1/+4
| | | | ok tb@
* Fix up MLKEM768_marshal_private_key to not use a passed in CBBbeck2025-05-192-27/+43
| | | | | | | | | | | | Even though this should remain internal, make it the same as the public key marshal function, and make the needed fallout changes in regress. This does not yet do the bikeshed of renaming the structure field in the regress ctx, that will wait until a follow on to convert 1024 in a similar manner ok tb@
* Remove the boringssl if || ideom from mlkembeck2025-05-192-34/+46
| | | | ok jsing@, joshua@
* API changes for ML-KEMbeck2025-05-194-78/+126
| | | | | | | | | - Get rid of CBB/CBS usage in public api - Make void functions return int that can fail if malloc fails. Along with some fallout and resulting bikeshedding in the regress tests. ok jsing@, tb@
* Simplify EVP AES code for ECB.jsing2025-05-192-33/+46
| | | | | | | | | | AES_ecb_encrypt() does not really do ECB - provide an aes_ecb_encrypt_internal that actually does multiple blocks and call this from aes_ecb_cipher(). Provide ECB with its own key initialisation function, which allows aes_init_key() to be simplified considerably. The block function pointer is now unused, so mop this up. ok joshua@ tb@
* Remove block128_f function casts.jsing2025-05-191-8/+20
| | | | | | | Provide aes_{en,de}crypt_block128() which have correct function signatures and use these when calling the various mode functions. ok joshua@ tb@
* Simplify EVP AES code for OFB.jsing2025-05-191-7/+19
| | | | | | | Provide AES-NI with its own aesni_ofb_cipher() and switch aes_ofb_cipher() to call AES_ofb128_encrypt() directly. ok joshua@ tb@
* Simplify EVP AES code for CFB.jsing2025-05-191-25/+79
| | | | | | | | Provide AES-NI with its own aesni_cfb*_cipher() functions, which then allows us to change the existing aes_cfb*_cipher() functions to () to call AES_cfb*_encrypt() directly. ok beck@ tb@
* EC_POINT_new: wording tweaks in the BUGS sectiontb2025-05-181-6/+6
|
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-08-24 10:51:14 +0000