summaryrefslogtreecommitdiff
path: root/src/lib (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* Remove disabled code supporting elliptic curves of small ordertb2024-12-241-1014/+1
| | | | ok jsing
* Tweak doc comment of _X509_CHECK_FLAG_DOT_SUBDOMAINStb2024-12-241-4/+3
| | | | | Now that it lives in a .c file, there's no need to point out that it is non-public...
* new manual page v2i_ASN1_BIT_STRING(3) written from scratchschwarze2024-12-246-11/+141
|
* Internal linkage for one constant struct where that was accidentallyschwarze2024-12-241-2/+2
| | | | | | | | | forgotten in rev. 1.3 on July 13 this year. No library bump and no ABI change because libcrypto.so.55.0 did not export the symbol because it wasn't in Symbols.list. Found in a partial code audit focusing on X509V3_EXT_METHOD objects.
* ealier -> earlierjsg2024-12-231-4/+4
|
* Move _X509_CHECK_FLAG_DOT_SUBDOMAINS to x509_utl.ctb2024-12-232-9/+9
| | | | | | | | Unclear why this ever had to be made public since it's only used in a single file. Anyway, nothing uses this, so remove it. This went through a full bulk pointed out by/ok schwarze
* Remove the EXT_* table building macrostb2024-12-231-19/+1
| | | | | | | | These were used in x509_bitst.c and x509_ia5.c for populating tables that have been expanded a long time ago. Nothing uses them, so remove them. This went through a full bulk pointed out by/ok schwarze
* Annotate ENUMERATED_NAMES for potential removaltb2024-12-231-1/+2
| | | | | Only security/xca uses it for no good rean. It can use BIT_STRING_BITNAME if it really needs to.
* Remove X509V3_EXT_{DYNAMIC,CTX_DEP}tb2024-12-231-4/+2
| | | | | | | | | | LibreSSL has removed support for dynamically allocated custom extension methods. The mysterious CTX_DEP define was part of an experimental code dump and that part of the experimental code was never shown hence never reviewed. This went through a full amd64 bulk noticed by/ok schwarze
* Fix the error handling in X509V3_parse_list(3); it ignored failuresschwarze2024-12-231-6/+9
| | | | | | | | | | | | | of the internal subroutine X509V3_add_value(), which could result in silently losing part of the input data on memory exhaustion. I independently rediscovered this bug while writing the documentation, then noticed after fixing it that Zhou Qingyang <zhou1615 at umn dot edu> fixed it in essentially the same way in OpenSSL 3 (commit bcd5645b on Apr 11 02:05:19 2022 +0800), but it wasn't backported to the OpenSSL 1.1.1 branch. OK tb@
* new manual page X509V3_parse_list(3) written from scratchschwarze2024-12-232-1/+102
|
* Tweak previous wording a bit to avoid suggesting all built-in nidstb2024-12-231-2/+2
| | | | | | correspond to an extension method. ok schwarze
* more precision below CAVEATSschwarze2024-12-231-3/+5
|
* Make the description of i2s_ASN1_ENUMERATED_TABLE(3) more precise,schwarze2024-12-231-9/+12
| | | | | fix the name of its last parameter in the SYNOPSIS to match the DESCRIPTION, and let the .Dt argument match the file name.
* mark six #define'd constants as intentionally undocumentedschwarze2024-12-221-2/+7
|
* Add an EXAMPLES section.schwarze2024-12-211-2/+129
| | | | | | | | | | | | | | | | I admit this is unusually long for a manual page. But that's not my fault as a documentation author. An example in a manual page ought to be minimal to show what needs to be demonstrated, and this example is minimal in that sense. Making it shorter without loosing important aspects does not seem possible. When an API is poorly designed, one of the consequences is that that documentation becomes harder to understand and often longer - in this case to the point of becoming outright intimidating. If people dislike that, they should design better APIs in the first place rather than blasting the poor manual page for being too long or too complicated. OK tb@
* If EVP_CIPHER_CTX_ctrl(3) is called on EVP_chacha20_poly1305(3)schwarze2024-12-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | with an unsupported control command, return -1 rather than 0 to the caller to indicate the error because in general, these control hooks ought to return -1 for unsupported control commands and 0 for other errors, for example other invalid arguments. Not a big deal because this change does not change when operations succeed or fail, and because callers are unlikely to pass unsupported control commands in the first place. The only functional change is that if a calling program inspects the ERR(3) stack after this failure, it will now find the correct error code rather than nothing. Even that wasn't a huge problem because for most EVP_CIPHER control failures, getting no reason for the error is the usual situation. Then again, giving the reason when easily possible may occasionally be useful. OpenSSL also returns -1 in this case, so it also helps compatibility a tiny bit. Found while auditing the return values of all the EVP_CIPHER control hooks in our tree. This was the only fishy one i found. OK tb@
* hidden mlkem.h: add comment to #endiftb2024-12-201-2/+2
|
* Annotate yet another greasy stinky tentacle of xcatb2024-12-201-1/+2
| | | | I'm so tired of this.
* Move the horrific EVP_aes_128_ccm(3) API out of the important,schwarze2024-12-204-75/+357
| | | | | | | | | | | | algorithm-independent EVP_EncryptInit(3) manual as another step in making the latter leaner and more palatable. As a side benefit, the new EVP_aes_128_ccm(3) manual page may provide a better fighting chance to programmers who see themselves forced to support CCM for whatever reason. It documents the mandatory, but so far undocumented EVP_CTRL_CCM_GET_TAG control command and makes the description of the three EVP_CTRL_CCM_SET_* control commands and the numerous related quirks more precise.
* Do not install mlkem.h and bytestring.h into /usr/include/openssl for nowtb2024-12-191-3/+1
| | | | | | More work in mlkem is needed and this was premature. discussed with beck and jsing
* #ifdef out the inclusion of openssl/mlkem.h for nowtb2024-12-191-3/+4
| | | | discussed with beck and jsing
* Do not assume mlkem.h and bytestring.h are public in libcryptotb2024-12-194-14/+8
| | | | | | | As long as is not quite clear what we want to do about the public API aspect of MLKEM, keep things internal for now. discussed with beck and jsing
* ec_mult: use 1ULL to avoid C4334 warning on Visual Studiotb2024-12-191-2/+2
| | | | | The shift is between 0 and 5 bits, so it doesn't matter, but VS is short for very st...ubborn as are its users when it comes to reporting non-issues
* received form the peer -> received from the peerjmc2024-12-191-3/+3
|
* mlkem: fix whitespacetb2024-12-182-4/+6
|
* kength -> lengthjsg2024-12-181-3/+3
|
* New manual page EVP_aes_128_gcm(3).schwarze2024-12-174-75/+260
| | | | | | | | | | | | The main benefit is moving the cumbersome and error-prone method of using EVP_EncryptInit(3) for AES-GCM out of the important, but obese manual page EVP_EncryptInit(3), and to create a logical place for pointing readers to the safer and more flexible EVP_AEAD_CTX_init(3). As a side benefit, document three control commands that were so far undocumented and make the description of three others more precise. Feedback and OK tb@.
* Avoid a reduce once that can cause Clang misoptomization.beck2024-12-172-22/+54
| | | | | | | | Some versions of Clang compile this to non-constant time code. The fix is adapted from boring. For full details see: https://boringssl-review.googlesource.com/c/boringssl/+/74447 ok tb@
* Plug two memory leaks in MLKEM*_generate_key_external_entropy()tb2024-12-172-2/+6
| | | | | | | This needs more thinking. These are void functions that allocate... Left an XXX for now. From Kenjiro Nakayama
* mlkem: clean up top matter in headerstb2024-12-172-8/+14
|
* Simplify ec_point_to_octets()tb2024-12-161-8/+3
| | | | | | | | | | | This had an extra dance to allow a NULL output buffer. The plan was to use this in i2o_ECPublicKey() to preserve the behavior of avoiding an allocation if out == NULL. However, when I rewrote the latter I punted on preserving that complication, as it was already batshit crazy enough. Thus, remove said dance and make ec_point_to_octets() cleaner. ok jsing
* Add ML-KEM 1024 from BoringSSLbeck2024-12-135-2/+1290
| | | | | | | | | | | | | | | Changes include conversion from C++, basic KNF, then adaptation to use our sha3 functions for sha3 and shake instead of the BorinSSL version. This Adds units tests to run against BoringSSL and NIST test vectors. The future public API is the same as Boring's - but is not yet exposed pending making bytestring.h public (which will happen separately) and a minor bump Currently this will just ensure we build and run regress. ok tb@ to get it into the tree and massage from there.
* KNF nit tb wanted me to fixbeck2024-12-131-2/+4
|
* Add ML-KEM 768 from BoringSSLbeck2024-12-135-1/+1412
| | | | | | | | | | | | | | | Changes include conversion from C++, basic KNF, then adaptation to use our sha3 functions for sha3 and shake instead of the BorinSSL version. This Adds units tests to run against BoringSSL and NIST test vectors. The future public API is the same as Boring's - but is not yet exposed pending making bytesring.h public (which will happen separately) and a minor bump Currently this will just ensure we build and run regress. ok tb@ to get it into the tree and massage from there.
* Rewrite a comment to use p rather than qtb2024-12-121-10/+10
|
* Rename group->field to group->ptb2024-12-124-52/+46
| | | | | | Now that we only do curves over GF(p) fields, there's no need to use a weird, confusing name for what we usually call p. Adjust some comments in the vicinity as well.
* sm3: fix ugly whitespacetb2024-12-121-5/+5
|
* appeared in 4.3BSD before 4.3BSD-Tahoejsg2024-12-1111-33/+33
| | | | ok millert@ schwarze@
* Avoid an oob access in asn1_item_free()tb2024-12-111-4/+3
| | | | | | | | | | As explained in a comment, this needs to loop backwards and the last tt-- ends up pointing at &it->templates[-1], which isn't ok. Use a simple way of looping, which is also ugly and involves some type confusion as pointed out by claudio. However, type confusion is common in libcrypto's asn1 code and won't be fixed anytime soon anyway. ok jsing
* Drop a pair of useless parenthesestb2024-12-111-2/+2
|
* Improve a rather misleading sentence about EVP_PKEY_new_mac_key(3).schwarze2024-12-101-4/+8
| | | | | | | It does *not* "work in the same way" as EVP_PKEY_new_raw_private_key(3) but merely arrives at the same end result after doing lots of cumbersome and unnecessary work - and on top of that, it only works for EVP_PKEY_HMAC.
* Add a paragraph about HMAC because that algorithm also involvesschwarze2024-12-101-3/+15
| | | | | | | | parameters that can be controlled with EVP_PKEY_CTX_ctrl(3). But rather than providing a detailed despription, instead point to what application programs should use instead and explain why using the control constant directly would be a particularly bad idea in this case.
* 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
* insert a forgotten .Dv macroschwarze2024-12-091-3/+3
|
* 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.
* 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.
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-19 23:40:27 +0000