summaryrefslogtreecommitdiff
path: root/src (follow)
Commit message (Collapse)AuthorAgeFilesLines
* ssl_sigalg_pkey_ok: allow RSASSA-PSS with pubkey OID RSASSA-PSStb2026-03-301-5/+6
| | | | | | | | | | | | This fixes a long-standing logic error that hasn't been noticed because we never announced the rsa_pss_pss_sha{256,384,512} SignatureScheme. The EVP_PKEY_id() of a RSA-PSS pubkey is EVP_PKEY_RSA_PSS, not EVP_PKEY_RSA. Thanks to beck for helping me figure out how to fix this correctly. It drove me nuts for a very long time. Problem also noticed by Tom Lane due to some PostgreSQL regress failures. ok djm jsing kenjiro
* ssl_sigalgs: whitespace tweaktb2026-03-301-1/+2
|
* ML-KEM: ensure that key_768 is only dereferenced with 768-bit keystb2026-03-291-3/+7
| | | | | | | | | This looks like a NULL dereference that should crash, but for some reason it doesn't, even with -O0 with all compilers i tried. At the very least it may result in compilers deducing that key_768 != NULL and lead to incorrect optimizations. ok claudio jsing kenjiro miod
* Add missing include path required to reach newly added crypto_assembly.hanton2026-03-291-2/+3
| | | | include.
* Include crypto_assembly.h instead of manually ensuring _CET_ENDBR exists.jsing2026-03-286-36/+12
| | | | ok kenjiro@ tb@
* Provide a crypto_assembly.h internal header.jsing2026-03-281-0/+30
| | | | | | | | | This will contain defines and macros that we need for assembly code, without polluting other headers that are primarily used for C code. For now, this just unconditionally provides _CET_ENDBR on amd64. ok kenjiro@ tb@
* libtls: const workarounds for X509_NAME in OCSP for OpenSSL 4tb2026-03-281-4/+5
| | | | | | | | | | | | | | The API to look up a cert by subject or issuer name clearly only needs to do name comparisons in a collection of certs so should by all means take a const X509_NAME * as an argument. However, this isn't all that easy to do and hence it's only in OpenSSL 4 that this obvious step was reached. This means that there is no way around casting for older code. One could cast the return value of X509_get_issuer_name() or the argument passed to the two lookups by subject. jsing slightly prefers the second approach, so this is what we do here. ok djm jsing kenjiro
* libtls: simple cases of const for X509_NAME *tb2026-03-282-6/+6
| | | | | | | | | | | After the const sprinkling in OpenSSL 1.1, X509_get_{issuer,subject}_name() still returned a non-const pointer for unclear reasons. In OpenSSL 4, the return value also grew a const qualifier, so move the two "name" in tls_conninfo.c and the "subject_name" in tls_verify.c to const. They are only used for further processing by already const correct functions (at least as far as X509_NAME is concerned). ok djm jsing kenjiro
* openssl speed: whitespace tweaktb2026-03-191-3/+3
|
* openssl speed: add benchmarking support for ML-KEMkenjiro2026-03-181-2/+179
| | | | | | | | | | | | | | | | | | | | | | | | | | Add support for benchmarking ML-KEM key encapsulation mechanisms to openssl speed. The following operations are measured: - key generation - encapsulation - decapsulation Two parameter sets are supported: mlkem768 mlkem1024 The benchmark can be invoked using the following options: mlkem run all ML-KEM benchmarks mlkem768 run ML-KEM-768 benchmarks mlkem1024 run ML-KEM-1024 benchmarks Results are reported similarly to other public key algorithms, showing time per operation and operations per second. Machine-readable output (-mr) support is also added for ML-KEM. ok tb
* sync with Mozilla root CA store, ok tb@sthen2026-03-181-174/+42
| | | | | | | | - remove CommScope CA (they requested it themselves; https://bugzilla.mozilla.org/show_bug.cgi?id=1994866) - add new cert: /C=HU/L=Budapest/O=Microsec Ltd./2.5.4.97=VATHU-23584497/CN=e-Szigno TLS Root CA 2023
* libcrypto: prefix EC_KEY methods with ec_key_tb2026-03-185-100/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We received reports that the too generic internal ecdsa_{sign,verify}() symbol names clash in some static links. The naming here is annoying because the EC_KEY_METHOD amalgamated the no longer existing ECDH and ECDSA methods which themselves had poorly chosen method names, still reflected in public API. There are various messes here. The ECDSA verify methods are declared in ec_local.h, whereas the ECDSA sign methods are in ecdsa_local.h (which is itself pretty useless and really only about EC_KEY_METHOD). I therefore merged the ECDSA method declarations into ec_local.h and deleted ecdsa_local.h since I see no real benefit to the latter. ecdsa.c needs ec_local.h anyway. Having the method declarations next to EC_KEY_METHOD seems sensible. I left the order as it was, matching ecdsa.c. The eckey_compute_pubkey() prototype should probably be moved down. With one exception I just added an ec_key_ prefix. This leads to a a repetition of 'key' in ec_key_ecdh_compute_key() which I chose to live with because it matches the public ECDH_compute_key() (mostly used by SSH implementations). The exception is ec_key_generate_key() where I expanded the gen() leading to another _key repetition but this then matches EC_KEY_generate_key(). Thanks to Rosen Penev for reporting and sending an initial diff. See also https://github.com/gsliepen/tinc/issues/478 ok jsing
* Move ECDSA_SIG_st definition to its only consumer, ecdsa.ctb2026-03-162-7/+7
|
* openssl.1: remove mention of OPENSSL_EC_BIN_PT_COMPtb2026-03-141-16/+2
| | | | | | | | The need for this compile time option enabling point compression for binary curves despite patent issues has been removed in openssl 1.0.0 (released in 2010). [It's really difficult to count the number of bad ideas in the above.]
* rfc3779 regress: explain where the range comes fromtb2026-03-131-1/+5
|
* rfc3779 regress: add an actual rangetb2026-03-131-1/+52
| | | | | | This improves the test coverage of make_addressRange() where there is an annoyance with unused bits in the RFC 3779 ASN.1 encoding versus trailing ones in the network encoding that the X509v3_addr_add_range() API expects.
* Fix BIO_get_mem_data(3) return value documentationtb2026-03-101-3/+18
| | | | pointed out by/ok dlg
* use the "e" flag with fopen() for O_CLOEXEC; ok tbderaadt2026-03-101-3/+3
|
* use O_CLOEXEC; ok tbderaadt2026-03-103-6/+6
|
* Use __pledge_open(2) for files that libc urgently needs even in lowerderaadt2026-03-102-10/+29
| | | | | | | | promise levels. You must be running a kernel at least 4 days old. Soon, another commit will happen that breaks compatibility even further, and you'll need new static binaries and new libc.so, along with a new kernel. This removes an old pledge design decision which is weak. Long discussions with david leadbeater and beck
* mlkem: use timingsafe_memcmp() in decapsulationkenjiro2026-03-061-2/+2
| | | | | | | | | | Replace memcmp() with timingsafe_memcmp() when comparing the re-encrypted ciphertext. FIPS 203 Section 6.3 defines this comparison result as a secret piece of intermediate data that must not be revealed in any form. ok tb
* nc(1) has the more crazy unveil + pledge configuration based uponderaadt2026-02-231-2/+4
| | | | | argument flags. I think this correctly replaces "tmppath" with an unveil.
* openssl x509: Remove legacy call to OBJ_create()kenjiro2026-02-081-4/+1
| | | | | | | The OID 2.99999.3 is not required for x509 output handling and is not referenced elsewhere. Remove the OBJ_create() call. ok tb jsing
* openssl x509: send -text output to the file specified by -outkenjiro2026-02-081-50/+44
| | | | | | | | | | | | | In the x509 command, `-text` output is not written to the file specified by `-out`, whereas in other OpenSSL/LibreSSL subcommands it is. With this change, STDout is removed, and `-text` output is written entirely to the file specified by `-out`, making the behavior consistent with other subcommands. Fix https://github.com/libressl/portable/issues/1228 ok tb jsing
* a_bitstr.c: fix includestb2026-02-081-3/+5
|
* More ec_point_cmp() turd polishingtb2026-02-081-45/+46
| | | | | | | | jsing prefers doing all computations first and comparing at the end. This means we do more work when we fail and no longer (ab)use err as an out label. Also split out one more helper. ok jsing
* Make truncation in ASN1_BIT_STRING_set_bit() explicittb2026-02-081-9/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of relying on i2c_ASN1_BIT_STRING() to determine the "unused" bits on encoding, set them explicitly in abs->flags via a call to asn1_abs_set_unused_bits(). This means ASN1_STRING_FLAGS_BITS_LEFT is now set on a bit string, which was previously explicitly cleared. This also means that the encoding of a non-zero ASN1_BIT_STRING populated by setting the bits individually will now go through the if (a->flags & ASN1_STRING_FLAG_BITS_LEFT) path in i2c_ASN1_BIT_STRING(). The most prominent usage of this function is in X.509 for the keyUsage extension or the CRL reason codes. There's also the NS cert type, TS PKIFailureInfo and general BITLIST config strings. The reason for the truncation logic comes from the DER for NamedBitLists X.690, 11.2.2 below: X.680, 22.7: When a "NamedBitList" is used in defining a bitstring type ASN.1 encoding rules are free to add (or remove) arbitrarily any trailing 0 bits to (or from) values that are being encoded or decoded. Application designers should therefore ensure that different semantics are not associated with such values which differ only in the number of trailing 0 bits. X.690, 11.2.2 Where ITU-T Rec. X.680 | ISO/IEC 8824-1, 22.7, applies, the bitstring shall have all trailing 0 bits removed before it is encoded. Note 1 - In the case where a size constraint has been applied, the abstract value delivered by a decoder to the application will be one of those satisfying the size constraint and differing from the transmitted value only in the number of trailing zero bits. Note 2 - If a bitstring value has no 1 bits, then an encoder shall encode the value with a length of 1 and an initial octet set to 0. ok kenjiro (on an earlier version) jsing
* replace buggy strncmp with strcmp found with clang-tidybcook2026-02-071-2/+2
| | | | | | Found the same fix from davidben in BoringSSL as well (https://boringssl-review.googlesource.com/c/boringssl/+/87927). OpenSSL appears to have accidentally changed the semantics here with the HAS_PREFIX macro, which appears to be incorrect. discussed w/ tb@ & beck@
* Implement s_client starttls protocol sieve.martijn2026-02-012-4/+62
| | | | | OK on previous diff concept sthen@ Suggestions, feedback and OK current diff tb@
* openssl asn1pars: move tmplen next to tmpbuftb2026-01-311-4/+4
|
* openssl asn1pars: avoid a few unnecessary caststb2026-01-311-11/+11
| | | | | | | | If str is a const unsigned char * rather than a char *, we can get away with a single cast and do not need to cast away const either. Reduce the scope of tmpbuf and ctmpbuf (now p) while there. ok kenjiro
* EVP_SealInit.3: fix RETURN VALUES sectiontb2026-01-301-2/+12
| | | | | | | | | While normal calls return 0 for error and npubk for success, there is a case where it returns the usual 1/0 thing. Make that explicit. Prompted by a report by Niels Dossche ok jsing kenjiro
* EVP_OpenInit.3: fix RETURN VALUES sectiontb2026-01-301-6/+4
| | | | | | | This has been incorrectly documented since forever. The function only ever returned 0/1. ok jsing kenjiro
* EVP_SealInit(): clear random key on exittb2026-01-301-2/+4
| | | | ok jsing kenjiro
* EVP_{Open,Seal}Init(): remove redundant EVP_CIPHER_CTX_reset() callstb2026-01-301-5/+1
| | | | | | The subsequent EVP_{Decrypt,Encrypt}Init_ex() calls already do that. pointed out by jsing
* EVP_SealInit(): minor cleanup.tb2026-01-301-11/+25
| | | | | | | | | | | | | | | | | Explicitly compare pointers against NULL, turn the function into single exit, add hint at why npubk <= 0 or pubk == NULL are a success path: The documentation briefly explains that EVP_OpenInit() and EVP_SealInit() is able to initialize the EVP_CIPHER_CTX in two steps exactly like the EVP_CipherInit_ex() API they wrap: the first call with non-NULL cipher (aka type) only sets the cipher on the ctx, then it returns to allow callers to customize the EVP_CIPHER_CTX, and a second call with cipher == NULL skips the initialization and finishes the ctx setup by setting key and iv. Prompted by a report by Niels Dossche. ok jsing kenjiro
* EVP_SealInit: do not return -1 on errortb2026-01-301-2/+2
| | | | | | | | It is documented that EVP_SealInit() returns 0 on error. So -1 is wrong. Reported by Niels Dossche ok jsing kenjiro
* EVP_OpenInit(): minor cleanuptb2026-01-301-9/+16
| | | | | | | | | Explicitly compare pointers against NULL, turn the function into single exit and explain why priv == NULL is a success (hint: muppet API). Prompted by a report by Niels Dossche. ok jsing kenjiro
* Avoid type confusion in the timestamp response parsingtb2026-01-271-1/+3
| | | | | | | | | | A malformed v2 signing cert can lead to a type confusion, and the result is a read from an invalid memory address or NULL, so a crash. Unlike for OpenSSL, v1 signing certs aren't affected since miod fixed this in '14. Reported by Luigino Camastra, fix by Bob Beck, via OpenSSL, CVE 2025-69420. ok jsing
* Avoid type confusion in PKCS#12 parsingtb2026-01-271-3/+9
| | | | | | | | | A type confusion can lead to a 1-byte read at address 0x00-0xff, so a crash. Reported by Luigino Camastra, fix by Bob Beck, via OpenSSL, CVE 2025-22795 ok jsing
* Add NULL pointer check to PKCS12_item_decrypt_d2i()tb2026-01-271-1/+6
| | | | | | | | Avoids a NULL pointer dereference triggerable by a malformed PCKS#12 file. From Luigino Camastra via OpenSSL (CVE-2025-69421) ok jsing
* assembly regress: use make's MACHINE_ARCH rather than handrolling ittb2026-01-251-4/+3
| | | | discussed with jsing
* Fix tyojsing2026-01-251-2/+2
|
* Hook assembly regressjsing2026-01-251-1/+2
|
* Add a regress test that ensures our pure assembly code builds with gccjsing2026-01-251-0/+36
| | | | | | This requires egcc to be installed, if not we'll just skip the test. Discussed with tb@
* Make SHA aarch64 assembly build with gcc.jsing2026-01-253-55/+72
| | | | | | | | | | | | | gcc is extremely fussy about register naming and insists on q and s naming for the ARM CE SHA instructions, even though they're referring to the same register (while LLVM just figures it out). Work around this by mapping registers to their required variant at usage and defining a handful of mappings between v registers and alternate names/views. This is still somewhat ugly, but seems to be one of the cleaner options that will allow portable to enable SHA assembly on platforms that use gcc. ok kenjiro@ tb@
* Tidy instruction separators in SHA assembly.jsing2026-01-247-113/+113
| | | | | Remove unnecessary separators and add a few to macros that call other macros (instead of expecting them to exist).
* unusally -> unusuallytb2026-01-233-30/+30
|
* bn_ffdh: unifdef HAVE_SCAPY_SPECIALtb2026-01-231-7/+1
|
* DH_check: teach this DoS vector about RFC 7919 primestb2026-01-231-1/+6
| | | | ok beck
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2026-06-05 22:23:04 +0000