openbsd/src/lib/libcrypto/rsa/rsa_ameth.c, branch OPENBSD_7_9A mirror of https://github.com/libressl/openbsd.git
https://git.lua4.win/openbsd/atom?h=OPENBSD_7_92026-04-07T13:16:41+00:00Rename labellen to label_len2026-04-07T13:16:41+00:00tb2026-04-07T13:16:41+00:00urn:sha1:825b6076f1b1772665d1adce40e8087ee4e3d091
Requested by jsing, ok beck
Fix NULL deref for malformed OAEP parameters in CMS decryption2026-04-07T13:15:29+00:00tb2026-04-07T13:15:29+00:00urn:sha1:e783182e57d664df5859c6b6cbd65563cdc26528
This converts rsa_cms_decrypt() to use X509_ALGOR_get0() and fixes a
NULL deref when a parameter is (invalidly) omitted similar to the fix
in ec/ec_ameth.c r1.66 from a couple years back. There is currently
an XXX annotating a hairy leak due to trying to be smart and stealing
the parameters from the oaep object. Instead, just make a copy of the
label string and free it in the exit path.
The diff adds an error for labellen == 0 since that is an invalid
encoding of pSpecifiedEmpty (see RFC 8017) -- per the DER the default
must be omitted. This way we avoid a malloc(0) implementation-defined
behavior.
This minor issue was assigned CVE-2026-28390 by OpenSSL and was reported
by too many to list. The fix is my own. It is similar to OpenSSL's fix
only because I rewiewed theirs and suggested an improvement or two.
This is the last of the "security fixes" in today's OpenSSL release that
"affect" LibreSSL. All the other bugs were already fixed a few years back
or we didn't have the code/bugs in the first place.
ok beck jsing
Use err_local.h rather than err.h in most places2025-05-10T05:54:39+00:00tb2025-05-10T05:54:39+00:00urn:sha1:41e8f99dd1625a9f0c80ce9d4383e95b18e85709
ok jsing
sort includes2024-11-02T07:11:14+00:00tb2024-11-02T07:11:14+00:00urn:sha1:c975c9b456e57c5865f4d9b623bf47a82decf566Only include cryptlib.h where it's needed2024-11-01T18:34:06+00:00tb2024-11-01T18:34:06+00:00urn:sha1:f9a68fe280d96dbf02f5338a1e3437222592c77b
Clean up the other includes while there.
Remove the pkey_{,public_,param_}check() handlers2024-08-29T16:58:19+00:00tb2024-08-29T16:58:19+00:00urn:sha1:c8099c070f0c547b73edced83591dbd871254307
This disables the EVP_PKEY_*check() API and makes it fail (more precisely
indicate lack of support) on all key types.
This is an intermediate step to full removal.
Removal is ok beck jsing
Implement X509_get_signature_info()2024-08-28T07:15:04+00:00tb2024-08-28T07:15:04+00:00urn:sha1:f822543d6a7043acc1d14a3e0b44eddc1051b097
This is a slightly strange combination of OBJ_find_sigid_algs() and the
security level API necessary because OBJ_find_sigid_algs() on its own
isn't smart enough for the special needs of RSA-PSS and EdDSA.
The API extracts the hash's NID and the pubkey's NID from the certificate's
signatureAlgorithm and invokes special handlers for RSA-PSS and EdDSA
for retrieving the corresponding information. This isn't entirely free
for RSA-PSS, but for now we don't cache this information.
The security bits calculation is a bit hand-wavy, but that's something
that comes along with this sort of numerology.
ok jsing
Annotate RSA-PSS SHA parameter encoding as wrong2024-03-17T07:10:00+00:00tb2024-03-17T07:10:00+00:00urn:sha1:ebd1b7f996341292ba9cf422de4db3d9afc32aec
A historic blunderfest in the ASN.1 module for RSA-PSS led to very
confusing text in various RFCs. davidben and my current reading of
this is that parameters for SHA-* should be encoded as an ASN.1 NULL
rather than omitted. The use of X509_ALGOR_set_evp_md() leads to them
being omitted, and is therefore counter to the specification (but
allowed. We should fix this. For now, leave a reminder.
See https://boringssl-review.googlesource.com/c/boringssl/+/67088
for a lot more details.
ok davidben
Inline rsa_is_pss() and rsa_pkey_is_pss()2024-01-10T14:59:19+00:00tb2024-01-10T14:59:19+00:00urn:sha1:7ec6c7c4fd30cef0339bceb9e61f996b3177e7a2
It's more explicit and not that much longer.
ok jsing
Replace .pkey_base_id with a .base_method pointer2024-01-04T17:01:26+00:00tb2024-01-04T17:01:26+00:00urn:sha1:9f1cd2582409ac5778c5a0e28dfb77f18d122c98
Every EVP_PKEY_ASN1_METHOD is either an ASN.1 method or an alias.
As such it resolves to an underlying ASN.1 method (in one step).
This information can be stored in a base_method pointer in allusion
to the pkey_base_id, which is the name for the nid (aka pkey_id aka
type) of the underlying method.
For an ASN.1 method, the base method is itself, so the base method
is set as a pointer to itself. For an alias it is of course a pointer
to the underlying method. Then obviously ameth->pkey_base_id is the
same as ameth->base_method->pkey_id, so rework all ASN.1 methods to
follow that.
ok jsing