summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Document tls_peer_cert_common_name()tb2024-12-101-2/+13
| | | | ok beck
* bump minor after symbol additiontb2024-12-101-1/+1
|
* expose tls_peer_cert_common_name()tb2024-12-101-0/+1
|
* Provide tls_peer_cert_common_name()tb2024-12-105-24/+105
| | | | | | | | | | | | | | | | There is currently no sane way of getting your hands on the common name or subject alternative name of the peer certificate from libtls. It is possible to extract it from the peer cert's PEM by hand, but that way lies madness. While the common name is close to being deprecated in the webpki, it is still the de facto standard to identify client certs. It would be nice to have a way to access the subject alternative names as well, but this is a lot more difficult to expose in a clean and sane C interface due to its multivaluedness. Initial diff from henning, with input from beck, jsing and myself henning and bluhm have plans of using this in syslogd. ok beck
* Mark four "struct *_st" types declared in evp.h as intentionally undocumentedschwarze2024-12-091-0/+2
| | | | | because they are intended as internal, and applications are supposed to use the documented aliases DH, DSA, EC_KEY, and RSA from ossl_typ.h instead.
* Mark four EVP_PKEY_GOST* constants as intentionally undocumentedschwarze2024-12-091-0/+2
| | | | because they are completely unused by anything.
* Mark two symbols as intentionally undocumentedschwarze2024-12-091-1/+3
| | | | that are obsolete after PBE was mostly removed from LibreSSL.
* insert a forgotten .Dv macroschwarze2024-12-091-3/+3
|
* Mark four EVP control constants as intentionally undocumentedschwarze2024-12-091-2/+3
| | | | that are only used for GOST.
* Mark the constants EVP_PK_*, EVP_PKS_*, and EVP_PKT_* as intentionallyschwarze2024-12-091-2/+7
| | | | | undocumented because they are only used by the function X509_certificate_type() which is deprecated and will eventually be deleted.
* Mark EVP_CTRL constants for RC5 as intentionally undocumentedschwarze2024-12-091-0/+1
| | | | | because LibreSSL does not support RC5 and because these constants are almost unused in the wild.
* Move the algorithm-specific functions EVP_rc2_*(3) out of EVP_EncryptInit(3)schwarze2024-12-084-55/+214
| | | | | | | | | and document them properly in their own manual page, including the control commands EVP_CTRL_SET_RC2_KEY_BITS and EVP_CTRL_GET_RC2_KEY_BITS that were so far undocumented. Arguably, the main benefit is another small step making the important, but still obese EVP_EncryptInit(3) manual page more palatable.
* Document the low-level rc2.h API.schwarze2024-12-072-2/+198
| | | | | Not that this would be particularly important, but i had to look at the code anyway while completing the EVP documentation.
* ec_mult: forgot to make one helper statictb2024-12-071-2/+2
|
* Move initialization of sign out of the middle of bits handlingtb2024-12-071-3/+3
|
* Rename ec_wNAF_mul() to ec_wnaf_mul()tb2024-12-063-7/+7
| | | | discussed with jsing
* ec_mult: manage wNAF data in a structtb2024-12-061-86/+131
| | | | | | | | | | | | | | | | | | | | | | This refactors the wNAF multiplication further and introduces a small API that manages the wNAF digits for bn and the multiples of digit * point in a single struct that is initialized and freed in two API calls in the main function, ec_wNAF_mul(). This way the main algorithm is no longer cluttered with logic to keep various arrays in sync, helper functions calculating the wNAF splitting of bn and multiples of the point do not need to deal with memory management, and a pair of accessors obviates previously missing bounds checking. At this point we have reached a relatively clean and straightforward wNAF implementation that fits precisely the purpose needed in libcrypto, i.e., ECDSA verification instead of being generalized and optimized to the max for no good reason apart from endowing the author with an academic degree. Popper's famous maxim "if you can't say it clearly, keep quiet, and keep working until you can" very much applies to code as well. In other words, shut up and hack (and don't pour too much energy into commit messages, tb). ok jsing
* Adjust the return type and value of EVP_MD_CTX_init(3)schwarze2024-12-062-7/+12
| | | | | and EVP_CIPHER_CTX_init(3) after tb@ changed these to OpenSSL 1.1 semantics in evp.h rev. 1.124 on March 2 this year.
* Delete the manual pages EVP_PKEY_meth_new(3) and EVP_PKEY_meth_get0_info(3)schwarze2024-12-0618-776/+60
| | | | | | | | because tb@ deleted almost all functions documented there from the API in evp.h 1.127 on March 2 this year, but move the functions EVP_PKEY_CTX_set_data(3) and EVP_PKEY_CTX_get_data(3) that we still support to EVP_PKEY_keygen(3), because that page already documents EVP_PKEY_CTX_set_app_data(3) and EVP_PKEY_CTX_get_app_data(3).
* Delete the manual page EVP_PKEY_check(3).schwarze2024-12-065-158/+5
| | | | | All three functions documented in this page were deleted from the API by tb@ in evp.h rev. 1.136 on August 31 this year.
* Delete the manual page EVP_PKEY_asn1_new(3).schwarze2024-12-0614-566/+30
| | | | | All the functions documented in this page were deleted from the API by tb@ in evp.h rev. 1.126 on March 2 this year.
* Provide a SHA-1 assembly implementation for amd64 using SHA-NI.jsing2024-12-063-2/+179
| | | | | | | | This provides a SHA-1 assembly implementation for amd64, which uses the Intel SHA Extensions (aka SHA New Instructions or SHA-NI). This provides a 2-2.5x performance gain on some Intel CPUs and many AMD CPUs. ok tb@
* Explain what "EVP" is supposed to mean.schwarze2024-12-061-2/+16
| | | | | | It's so non-obvious that even i had to do some research to find out. Source: The file "doc/ssleay.doc" from SSLeay 0.8.1b, see for example OpenSSL commit d02b48c6 on Dec 21, 1998.
* Fix previous and thus regress failures reported by antontb2024-12-061-2/+3
| | | | Looks like I applied the diff to a dirty tree and didn't notice.
* ec_asn1: update a comment to match realitytb2024-12-061-2/+2
|
* Set nid on group decoded from EC parameterstb2024-12-063-7/+14
| | | | | | | | | | | | | We match curve parameters against the builtin curves and only accept them if they're encoding a curve known to us. After getting rid of the wtls curves, some of which used to coincide with secp curves (sometimes the wrong ones), the nid is unambiguous. Setting the nid has no direct implications on the encoding. This helps ssh avoid doing ugly computations during the key exchange for PEM keys using this encoding. ok djm joshua jsing
* Zap a trailing spacetb2024-12-052-4/+4
|
* Make the DSS_prime_checks macro internaltb2024-12-052-11/+12
| | | | | | | | Rename it to DSA_prime_checks and add an XXX comment mentioning that we could reduce the number of rounds thanks to BPSW. There are no plans of changing that as DSA is on its way out. discussed with miod
* Remove the undocumented DSA_is_prime() macrotb2024-12-051-3/+1
| | | | | | It aliases BN_is_prime(), which was removed in April 2023. makes sense to miod
* document the #define'd constant PKCS5_SALT_LENschwarze2024-12-051-4/+6
|
* drop comments asking for documentation of three ASN1_PKEY_CTRL_CMS_*schwarze2024-12-051-5/+2
| | | | | constants after these have been marked as intentionally undocumented; they are internal to the library and unused in the wild
* Mark three EVP_PKEY control constants for CMS as intentionally undocumentedschwarze2024-12-051-0/+2
| | | | that are internal to the library and unused in the wild
* mark three more EVP_PKEY control constants as intentionally undocumentedschwarze2024-12-051-0/+3
| | | | that are only intended for internal use and unused in the wild
* ignore DECLARE_PKCS12_STACK_OF such that pkcs12.h can be parsedschwarze2024-12-051-0/+1
|
* Apply a little bit of lipstick to PKCS7tb2024-12-051-3/+7
| | | | | | | Makes the setting and getting of detached signatures more symmetric and avoids a NULL access. ok jsing
* Use ASIdentifiers rather than struct ASIdentifiers_sttb2024-12-041-2/+2
| | | | | | This matches the other members of X509 and is what's used everywhere else. ok miod
* Another now unused perlasm script can bite the dust.jsing2024-12-041-1267/+0
|
* Provide a replacement assembly implementation for SHA-1 on amd64.jsing2024-12-043-2/+345
| | | | | | | | | | | | | As already done for SHA-256 and SHA-512, replace the perlasm generated SHA-1 assembly implementation with one that is actually readable. Call the assembly implementation from a C wrapper that can, in the future, dispatch to alternate implementations. On a modern CPU the performance is around 5% faster than the base implementation generated by sha1-x86_64.pl, however it is around 15% slower than the excessively complex SSSE2/AVX version that is also generated by the same script (a SHA-NI version will greatly outperform this and is much cleaner/simpler). ok tb@
* Annotate WTLS7 as being wrongtb2024-12-041-1/+2
| | | | | | | This should really have been using SECP 160R2, not SECP 160R1. Of course this means in particular that nobody ever used this curve, at least not against another implementation than OpenSSL. Quasi-monocultures are poisonous whether the monopolist is benevolent and competent or not.
* Fix up authority and subject key identifiers in force pubkey modetb2024-12-041-8/+133
| | | | | | | | | | | | Upstream decided that this nonsense was worth an ABI break and added stuff to the X509_CTX so they could hang the issuer's public key off it so that they could adjust the key identifiers as needed. Let's avoid that and do it the slightly less nasty way by updating the AKI and SKI as needed. We only do this when force pubkey is in place so we don't change the semantics of the batshit crazy config language that nobody understands. ok job
* Fix debug output for http headerstb2024-12-041-5/+4
| | | | from Kenjiro Nakayama
* Meant to split the sentence in twotb2024-11-301-3/+3
|
* Be a bit more precise on the error conditions of CMS_get1_{certs,crls}()tb2024-11-301-3/+4
|
* Explain how to free the stack returned by CMS_get1_{certs,crls}()tb2024-11-301-2/+9
| | | | with job
* Inline trivial EC point methodstb2024-11-303-95/+23
| | | | | | | | | Like most of the "group" methods these are shared between Montgomery curves and simple curves. There's no point in five methods hanging off the EC_METHODS struct whne they can just as well be inlined in the public API. It makes all files involved shorter... ok jsing
* Get BNs Z coordinates from the BN_CTXtb2024-11-301-8/+3
| | | | | | | | While there likely won't be enough BNs already available in the ctx, and thus it won't greatly reduce the amount of allocated BNs, it simplifies the exit path quite a bit. review feedback from jsing
* Improve ec_points_make_affine()tb2024-11-301-119/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | It is unclear how the original code was supposed to work. It clearly missed a few corner cases (like handling points at infinity correctly) and the badly mangled comment that was supposed to display a binary search tree didn't help at all. Instead do something much more straightforward: multiply all the non-zero Z coordinates of the points not at infinity together, keeping track of the intermediate products. Then do a single expensive modular inversion before working backwards to compute all the inverses. Then the transformation from Jacobian coordinates to affine coordiantes (x, y, z) -> (x/z^2, y/z^3, 1) becomes cheap. A little bit of care has to be taken for Montgomery curves but that's very simple compared to the mess that was there before. ok jsing This is a cleaned up version of: commit 0fe73d6c3641cb175871463bdddbbea3ee0b62ae Author: Bodo Moeller <bodo@openssl.org> Date: Fri Aug 1 17:18:14 2014 +0200 Simplify and fix ec_GFp_simple_points_make_affine (which didn't always handle value 0 correctly). Reviewed-by: emilia@openssl.org
* openssl speed: stop trying to use small curvestb2024-11-301-25/+11
| | | | | | | secp160r1 and nistp192 are no longer available in libcrypto. Should have been committed along with disabling these curves, but was missed. ok jsing
* Don't leak the abuf on error in PKCS7_dataFinal()tb2024-11-301-1/+2
| | | | ok beck miod
* Remove X9.42 DH rudimentstb2024-11-293-19/+7
| | | | | | | | | In the unlikely event that we should ever decide to implement this after a quarter century of not needing it, we can readily put this back. Until then this is dead weight. prompted by a question by djm ok jsing
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-25 21:43:33 +0000