summaryrefslogtreecommitdiff
path: root/src/lib (follow)
Commit message (Collapse)AuthorAgeFilesLines
* bn_prime.c: fix includesHEADmastertb10 days1-3/+4
|
* move the sentence about X509_VERIFY_PARAM_get_hostflags(3)schwarze11 days1-6/+7
| | | | | | to the right section and mention the value returned if X509_VERIFY_PARAM_set_hostflags(3) was never called; OK tb@ kenjiro@
* Use 64 bit BN_ULONG on 64 bit Windows platforms.jsing11 days1-2/+2
| | | | | | | | 64 bit Windows is a special LLP snowflake and it is currently incorrectly using 32 bit BN_ULONG, since _LP64 is not defined. Enable 64 bit BN_ULONG if _LP64 or _WIN64 is defined. ok tb@
* tweak previous: "functions returns" -> "functions return"schwarze12 days1-4/+4
| | | | and add a missing Oxford comma
* Use BN_ULONG in probable_prime_dh()tb13 days1-2/+2
| | | | | | | | | This was the last user of BN_LONG in code. It had no reason to do so. BN_mod_word() returns a BN_ULONG and since the largest prime in the small primes table primes[] is well below 20000, the only return value that could cause 'mod' to be negative was the error sentinel (BN_ULONG)-1. ok jsing kenjiro
* Use more specific types for BN.jsing13 days1-27/+29
| | | | | | | | | | | Be specific about width and use uint64_t/uint32_t, rather than using unsigned int/long/long long, based on platform. Additionally use UINT64_C() and UINT32_C() for constants, along with PRI*64/PRI*32 for formatting. This makes the platform responsible for providing the correct types/defines - all we then need to do is determine is if BN should use a 32 bit or 64 bit configuration. With input from and ok tb@
* In nref_nos() don't leak the ASN1_INTEGER if the push failstb2025-11-031-2/+4
| | | | | | | (A much bigger problem here is a double free for which I will send out a diff shortly) From Niels Dossche
* x509_cpols: pass correct free function to sk_ASN1_INTEGER_free()tb2025-11-031-2/+2
| | | | from Niels Dossche
* x509_cpols: indent labels to make diffs more readabletb2025-11-031-8/+8
|
* Plug memeory leak in CMS_EncryptedData_encrypt()tb2025-11-031-2/+4
| | | | | | If CMS_EncryptedData_set1_key() fails, cms is leaked. From Niels Dossche
* ec_curve: Remove outdated creditstb2025-11-021-4/+1
|
* des_key: add missing hyphen in semi-weak keystb2025-10-271-2/+2
| | | | From Thorsten Blum
* Simplify tls13_server_hello_build()tb2025-10-251-5/+5
| | | | | | | | There's no need to pass in the hrr parameter as it is redundant with the tls13.hrr flag. This avoids boolean blindness in the caller and removes a leftover from before we had tls13.hrr. ok jsing kenjiro
* Add missing Nm line for SSL_SESSION_duptb2025-10-241-2/+3
|
* bump lib{crypto,ssl,tls} minors after symbol additiontb2025-10-243-3/+3
|
* Document SSL_SESSION_dup(3)tb2025-10-241-3/+20
| | | | ok kenjiro
* Provide SSL_SESSION_dup()tb2025-10-244-3/+13
| | | | | | | As reported by ajacoutot and sthen, an update to net/neon is blocked on that missing symbol. ok kenjiro
* Document X509_VERIFY_PARAM_set_hostflags(3)tb2025-10-241-2/+15
| | | | ok kenjiro
* Expose X509_VERIFY_PARAM_get_hostflags()tb2025-10-244-4/+7
| | | | | | | | | | | | | | This is needed by Python 3.14, extending the urllib3 nonsense further. This is a trivial getter and it is exercised by the libssl unit test I added for urllib3 (which can now use dynamic linking for libcrypto). Fixes https://github.com/libressl/portable/issues/1202 Thanks to @orbea for the report. ok kenjiro PS: X509_VERIFY_PARAM_get_flags() and X509_VERIFY_PARAM_get_peername() aren't const correct. Fixing this will require some doing...
* Implement ffsl() and ffsll() using the compiler builtin __builtin_ctzlclaudio2025-10-244-11/+66
| | | | | | now that all archs use at least gcc4. ffsl() and ffsll() are now part of POSIX. OK deraadt@, input from miod@ and jsg@
* libssl: const correct the ssl_session_dup() helpertb2025-10-242-5/+5
| | | | | | | | | This allows a const correct SSL_SESSION_dup() implementation at the cost of casting away const due to the const incorrect CRYPTO_dup_ex_data()... (I should look into fixing that, but things like rust-openssl make that hard at this point in the release cycle.) ok kenjiro (as part of a larger diff)
* Prepare for gcc 3 leaving the building, COMPILER_VERSION can no longer getmiod2025-10-231-4/+4
| | | | set to "gcc3".
* Revert r1.286 now that all supported platforms have __builtin_clz.miod2025-10-231-20/+1
|
* Ensure that we specify the correct group when creating a HelloRetryRequest.jsing2025-10-162-9/+4
| | | | | | | | | | | | | | | | | When processing the client supported groups and key shares extensions, the group selection is currently based on client preference. However, when building a HRR the preferred group is identified by calling tls1_get_supported_group(). If SSL_OP_CIPHER_SERVER_PREFERENCE is enabled, group selection will be based on server instead of client preference. This in turn can result in the server sending a HRR for a group that the client has already provided a key share for, violating the RFC. Avoid this issue by storing the client preferred group when processing the key share extension, then using this group when creating the HRR. Thanks to dzwdz for identifying and reporting the issue. ok beck@ tb@
* const correct X509_VERIFY_PARAM_get_hostflags()tb2025-10-101-2/+2
| | | | | | | This is currently an internal helper only used by a regress test. We'll have to expose in the public API for Python 3.14: https://github.com/libressl/portable/issues/1202
* Remove unused sequence member from x509_revoked_sttb2025-10-102-11/+2
| | | | | | | | | | | | | | | | | To allow binary search for looking up if a cert was revoked in a CRL, the list of revoked serial numbers is sorted in crl_lookup(). On the other hand, to be able to output the DER that was actually signed by the issuer, the original order needs to be remembered. Before the encoding was cached, there was a mechanism that would restore the original order on serialization using the .sequence member. This was done without a lock and was thus racy (hilarity would ensue if one thread performed a CRL lookup while another thread serialized the same CRL). When the racy mechanism was removed in 2004, the only reader of .sequence, X509_REVOKED_seq_cmp(), was also removed, and this piece of dead code was left behind. Garbage collect it. ok kenjiro
* cms: fix incorrect length check in kek_unwrap_key()tb2025-09-301-2/+2
| | | | | | | | | | An incorrect length check can result in a 4-byte overwrite and an 8-byte overread. From Stanislav Fort and Viktor Dukhovni via OpenSSL. CVE-2025-9230. ok jsing
* cms_RecipientInfo_pwri_crypt: fix incorrect return checktb2025-09-301-3/+3
| | | | ok jsing
* cms_RecipientInfo_pwri_crypt: plug leak of kekalgtb2025-09-301-3/+3
| | | | ok jsing
* libcrypto: rsa gen: min. distance between p and qjan2025-09-291-3/+19
| | | | | | | | | | | | | | | | | This is required in NIST Special Publication 800-56B Revision 2 "Recommendation for Pair-Wise Key Establishment Using Integer Factorization Cryptography": 6 RSA Key Pairs 6.2 Criteria for RSA Key Pairs for Key Establishment 6.2.1 Definition of a Key Pair 3. The prime factors p and q shall be generated using one of the methods specified in Appendix B.3 of FIPS 186 such that: c. |p – q| > 2nBits/2−100 ok djm@, tb@
* Bump libressl version to 4.2.0tb2025-09-281-3/+3
| | | | | The version check will break the rust-openssl regress unless you have rust-openssl-tests-20250927p0.
* Revert NULL,0 -> OPENSSL_FILE,OPENSSL_LINE from r1.78tb2025-09-281-9/+9
| | | | | | | | | | | This wasn't part of the initial proposal and causes issues in curl downstream. We could pile more hacks on top of this, but at some point this is getting too silly. Relatedly, most of the FOOerr() could be removed, although PEMerr(), RSAerr() and SSLerr() are used by some downstreams and probably not worth patching out. Discussed with @vszakats in https://github.com/libressl/portable/issues/1154
* mlkem_generate_key_external_entropy: normalize sizeof() usetb2025-09-161-2/+2
|
* Simplify MLKEM_{private,public}_key_new()tb2025-09-161-19/+7
| | | | | | | This removes two unnecessary variables in each of these functions, normalizes the sizeof() use and undoes unnecessary line wraps. ok deraadt djm kenjiro
* aes: move explicit_bzero() after NULL checktb2025-09-151-5/+7
| | | | | | CID 621601 621602 ok djm jsg jsing miod
* MLKEM_private_key_new: add missing space before =tb2025-09-151-2/+2
|
* mlkem_public_to_private: fix overread/information leaktb2025-09-141-3/+3
| | | | | | | | | | | | After the guts of MLKEM_public_key were changed from a union to a struct, the aligner grew the struct, leaking as many bytes of private key data as the struct grew (on normal platforms that would be 2). Ideally this would all be a bit more robust. CID 621603 621604 ok jsing kenjiro
* Call aes_set_encrypt_key_generic() from aes_set_decrypt_key_generic().jsing2025-09-081-2/+2
| | | | | With the renaming, aes_set_decrypt_key_generic() should now call aes_set_encrypt_key_generic() directly.
* Allow generic AES implementation to be used as a fallback.jsing2025-09-083-19/+65
| | | | | | | | | Rename the C based AES implementation to *_generic() and provide *_internal() wrappers for these. This allows for architectures to provide accelerated versions without having to also provide a fallback implementation. ok tb@
* Zero the round keys on AES_set_{en,de}crypt_key() function entry.jsing2025-09-081-1/+5
| | | | | | | This avoids leaving previous round keys around on failure, or leaving parts of previous round keys behind if reused with a smaller key size. ok tb@
* Validate AES_set_{encrypt,decrypt}_key() inputs at API boundary.jsing2025-09-082-18/+28
| | | | | | | | | | | Every aes_set_{encrypt,decrypt}_key_internal() implementation is currently required to check the inputs and return appropriate error codes. Pull the input validation up to the API boundary, setting key->rounds at the same time. Additionally, call aes_set_encrypt_key_internal() directly from aes_set_decrypt_key_internal(), rather than going back through the public API. ok tb@
* Remove BN_DIV2W.jsing2025-09-073-28/+4
| | | | | | | The BN_DIV2W define provides a code path for double word division via the C compiler, which is only enabled on hppa. Simplify the code and mop this up. ok tb@
* Re-enable bn_sqr_words() assembly.jsing2025-09-073-8/+8
| | | | This is now only on amd64.
* Rename old assembly bn_sqr_words() to bn_sqr_word_wise().jsing2025-09-076-30/+27
| | | | | | | bn_sqr_words() does not actually compute the square of the words, it only computes the square of each individual word - rename it to reflect reality. Discussed with tb@
* Deduplicate the mlkem 768 and mlkem 1024 code.beck2025-09-056-1788/+527
| | | | | | | | | | | This moves everything not public to mlkem_internal.c removing the old files and doing some further cleanup on the way. With this landed mlkem is out of my stack and can be changed without breaking my subsequent changes ok tb@
* Disable assembly bn_sqr_words() again for now.jsing2025-09-023-8/+8
| | | | | | | | The old assembly bn_sqr_words() does not actually square words in the bignum sense. These will have to be renamed (once I come up with a name for whatever it actually does) before we can roll forward again. Found the hard way by Janne Johansson.
* Add const here as well...jsing2025-09-011-2/+2
|
* Use bn_mul_words() from bn_mod_mul_words().jsing2025-09-011-5/+3
| | | | | | Use bn_mul_words() and bn_montgomery_reduce_words(), rather than using bn_montgomery_multiply_words(). This provides better performance on architectures that have assembly optimised bn_mul_words(), such as amd64.
* Constify bn_mul_words().jsing2025-09-013-6/+9
|
* Use bn_sqr_words() from bn_mod_sqr_words().jsing2025-09-011-5/+3
| | | | | | | | Use bn_sqr_words() and bn_montgomery_reduce_words(), rather than using bn_montgomery_multiply_words(). This provides better performance on architectures that have assembly optimised bn_sqr_words(), such as amd64. ok tb@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-11-18 22:42:28 +0000