Update-Note: ASN1_TIME, DIRECTORYSTRING, and DISPLAYTEXT are no longer
usable in custom macro-based ASN.1 types using <openssl/asn1t.h>. There
do not seem to be any external callers that depend on this.
If this sticks then, after all the built-in types are rewritten, we may
be able to remove MSTRING from tasn_* altogether!
Bug: 42290417
Change-Id: Ia12d8767bcada8eda75550e13bbab5a4a572382c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/81729
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Keeping it to X25519/Ed25519 for now, but arguably we could pick "raw"
options for most of our keys. The problem is just when there's a couple
different options. (ECPrivateKey or just the serialized scalar for EC
keys, compressed vs uncompressed points.)
Bug: 42290364
Change-Id: I1e1a0a3fa971f27a962946301091ebe11bac2725
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/81667
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
While, in principle, PSS is better than PKCS#1 v1.5, and
algorithm-specific keys are better than mixing them up, RSASSA-PSS was
so badly mis-standardized in RFC 3447 and RFC 4055 that this is not
worth it. Any marginal benefits one might get from PSS is completely
overshadowed by the mountain of unforced errors those two RFCs made.
Applications are better off just using ECDSA.
Nonetheless, it is a thing we are now supporting. Add off-by-default
support for EVP_PKEY_RSA_PSS, only using the SHA-256 parameter set. In
OpenSSL's implementation, the underlying RSA object stores an
RSA_PSS_PARAMS, though the RSA-level APIs don't enforce the parameters,
only the EVP-level APIs do. For now, since the SHA-256 parameters are
the only ones we support, I have not bothered adding extra state to the
RSA object. If we need to add more parameters, we can store the
rsa_pss_params_t enum on the RSA object. (Preferably after we've split
the BCM and non-BCM halves of the RSA object.)
This support is off by default and must remain so. We have a bit of a
mess API-wise: OpenSSL made EVP_PKEY_get0_RSA work with
EVP_PKEY_RSA_PSS. This is plausible in that applications may want to
inspect RSA components and that is, for now, the API to do so. However,
existing callers generally assume a non-NULL EVP_PKEY_get0_RSA return
implies EVP_PKEY_RSA. Changing this will break those callers.
Thus the opt-in not only limits a badly-designed key type, but also
prevents existing callers from being exposed to this unexpected state.
These keys are not wired up to libssl and we have no plans to do so.
Bug: 384818542
Change-Id: I4d99be86ce1d891a2e50335ef097913707ede55a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/81656
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
For now this is just used by the X.509 verification logic and supports
the three sets of parameters we accept. Later EVP_PKEY_RSA_PSS will use
the same parser.
Bug: 384818542
Change-Id: I4d9a83283cbf239268f37d814f00d0b6ec3b46f2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/81655
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This adds new SPKI and PKCS#8 parser entrypoints that pass in the list
of allowed algorithms. Algorithms are expressed as EVP_PKEY_ALG
functions and roughly things that can create EVP_PKEYs in various ways.
(Right now just SPKI and PKCS#8 parsers, but I'm imagining that they'll
also be the handle for the "raw" public/private key parsers and things
like the list of curves for ECPrivateKey or X9.62 points.)
The immediate motivation is to give a handle for opting into
EVP_PKEY_RSA_PSS (we don't want most applications to be exposed to
those), but I'm hoping this can also:
- Let us add legacy or experimental algorithms for one caller without
worrying about exposing all callers to them.
- Let size-constrained applications use EVP without worrying about
binary size.
- Reduce the need for people to check the key type after parsing keys. I
would like to it eliminate the need, but RSA having a continuum of
sizes makes things tricky. For now, EVP_pkey_rsa() just accepts all
supported RSA sizes (512 through 8192, but hopefully we can clamp it
down).
While we're here, correct what, in hindsight, were I think some missteps
in the EVP_parse_public_key convention:
- Not saying the name of the format in the function name. Since I expect
we'll add EVP_PKEY_from_ec_private_key, EVP_PKEY_from_rsa_private_key,
etc., functions to start filling out EVP, having the name of the
format would have been nice.
- Taking an in/out CBS parameter. As an in/out parameter, we don't check
trailing data and just pass it to the caller to check. This optimized
for parsing an SPKI inside a structure, rather than standalone. In
practice, folks forget to check trailing data.
In comparison to OpenSSL 3.x, I think an EVP_PKEY_ALG is roughly an
OSSL_KEYMGMT, but that's a very confusing name. Maybe also with bits of
the OSSL_DECODER in there. Mostly I don't understand their very
complicated (and apparently quadratic-time) decoder system.
OpenSSL 3.x also has an OSSL_LIB_CTX which has been threaded into a
bunch of objects. Having BoringSSL's OSSL_LIB_CTX carry a list of these
things would be plausible, but different call sites within a single
application may support different algorithms, so let's start with the
explicit list approach and see where we go from there.
Bug: 42290364
Change-Id: I342603efdc167c8f587357d17800d7ad545d5908
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/81651
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Checking for an error on the error queue is very tedious. You have to
check both library and reason code separately, which often means you
need to save the error code to a local variable.
Make an ERR_equals function. I've gone ahead and just made it public API
because even within BoringSSL, it seems to come up everywhere.
Change-Id: Ia963c9ae743ac5c6939846f8f64bbc98b495ce0b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/81627
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Per the docs, the only real use case is setting EVP_PKEY_X25519. Outside
BoringSSL, the one caller using other key types to make test keys has
since been fixed. One call to EVP_PKEY_set_type(EVP_PKEY_NONE) remains,
but this CL does not break it.
This removes one path to making this flavor of half-empty keys for all
but X25519, where we're forced to have such keys for OpenSSL
compatibility.
Update-Note: EVP_PKEY_set_type will now only succeed for
EVP_PKEY_X25519. EVP_PKEY_set_type(EVP_PKEY_NONE) will continue to clear
the pkey and then fail. Going through code search, there are not
expected to be any affected callers.
Bug: 42290409
Change-Id: I20ca762be71f71a628f5894045e5b66b7773c215
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/81548
Reviewed-by: Lily Chen <chlily@google.com>
Commit-Queue: Lily Chen <chlily@google.com>
EC_KEY_KEY looks very silly. In OpenSSL, this is
EVP_R_EXPECTING_A_EC_KEY. It's a little odd that they say "a EC key"
instead of "an EC key", but ah well. (They do say "an RSA key".) May as
well match.
Update-Note: Code search finds no references to the BoringSSL name, so
this is not expected to impact anything.
Change-Id: I7563645fd269e4a62fbc46de2647f06bde00e1e4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/81428
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Lily Chen <chlily@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Lily Chen <chlily@google.com>
Given OpenSSL puts it all in one header, I don't think we can ever make
<openssl/evp.h> stop including <openssl/digest.h>. Best we can do is
move the public/private key stuff into its own header and make
<openssl/evp.h> be the compat one.
Change-Id: I60310630657513a1cb410cd401ae7e80b1c16913
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/81408
Commit-Queue: Lily Chen <chlily@google.com>
Reviewed-by: Lily Chen <chlily@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Kyber was the prestandard version of ML-KEM. Callers should be using
ML-KEM now. For now, keep the implementation behind an internal header
for libssl, but we expect to remove that soon too.
Update-Note: <openssl/experimental/kyber.h> is gone. Use
<openssl/mlkem.h> instead.
Bug: 438787615
Change-Id: I02919e5d627dcbe863e70e433c79e360a556d462
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/81287
Reviewed-by: Lily Chen <chlily@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This function is practically useless. It makes a typed but empty key,
which is somehow distinct from an untyped and empty key. Looking for
callers within our tests and externally, the patterns are:
- EVP_PKEY_set_type(EVP_PKEY_X25519) followed by
EVP_PKEY_set1_tls_encodedpoint. This is regrettably needed for that
API to work, but we've also marked EVP_PKEY_set1_tls_encodedpoint as
deprecated, I think because of this weird half-empty state. Sadly this
means we can never totally remove this, and we're stuck with some of
these half-empty states.
- EVP_PKEY_set_type(EVP_PKEY_NONE). This is used in some tests by
callers who try to test their "unknown type" codepaths. The usual
pattern is they load a key and then set the type to EVP_PKEY_NONE.
The result of this is an empty EVP_PKEY, identical to just calling
EVP_PKEY_new. Loading the key was never useful. It's also an error!
The function fails because EVP_PKEY_NONE is not a supported type.
Callers were relying on a quirk that we clear the key before noticing
the parameters are wrong. Write a test and update the comment so we
don't forget this behavior is depended on. (Though I'm going to try to
fix everyone relying on this.)
- EVP_PKEY_set_type(EVP_PKEY_RSA), etc. This does not produce a valid
key. It's done in some test code to avoid loading a real key. Our own
tests do this too, though it's also to test that
EVP_PKEY_missing_parameters works for this weird empty state, that
ideally wouldn't be possible in the first place.
The immediate motivation is that the work to make EVP more
static-linker-friendly collides a bit with
EVP_PKEY_set_type(EVP_PKEY_EC). If we're trying to treat P-256 and P-384
as distinct EVP_PKEY types, it's unclear how that operation is supposed
to work.
Bug: 42290409
Change-Id: Id4368e049abea698f0eaed1419cb366a5fe3a424
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/81269
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Lily Chen <chlily@google.com>
Commit-Queue: Lily Chen <chlily@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Upcoming NIST rule changes are expected to effectively require us to
pass in larger entropy inputs to the DRBG, which requires us to use the
"derivation function" option from 800-90A.
This change implements the derivation function and splits the entropy
and nonce arguments out, as needed for this style of DRBG.
Since we have external users of the existing CTR-DRBG mode, that is
still supported, but all internal uses will now use a derivation
function.
Change-Id: I8079e9f4c6238e91c68fef1e40189211f4142555
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/79768
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
85730f21f9 added sha2.h to split out SHA-1. It also updated a number of
files to use sha2.h rather than sha.h. But some external users are
assuming that they get SHA-1 transitively from other headers. Rather
than break them, back off on this on crypto.h. We'll see if x509.h
survives for now.
Change-Id: Iddbb2096c76cd608e3ada0942f87b8b54786d7ca
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/80387
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Historically, sha.h included both SHA-1 and SHA-2 functions. But SHA-1
functions mostly shouldn't be used now, and it's useful to be able to
audit at the level of header names in some contexts.
Therefore move SHA-2 things into a new sha2.h. In order not to break
everything, sha.h now includes sha2.h so no changes are needed in
existing callers.
Change-Id: I68d5e991f58a1c74ca377ba017caaff356acc870
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/80327
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
RSA-8192 is already too big. This avoids needing to worry about
bn_mul_mont allocating more than a page of stack memory, makes it a lot
more comfortable to just stack-allocate all Montgomery temporaries.
Also RSA operations scale quadratically or cubicly. For reference, on my
machine:
Did 1638 RSA 2048 signing operations in 1015740us (1612.6 ops/sec)
Did 82000 RSA 2048 verify (same key) operations in 1000238us (81980.5 ops/sec)
Did 70000 RSA 2048 verify (fresh key) operations in 1001850us (69870.7 ops/sec)
Did 13580 RSA 2048 private key parse operations in 1013849us (13394.5 ops/sec)
Did 611 RSA 3072 signing operations in 1038497us (588.4 ops/sec)
Did 39000 RSA 3072 verify (same key) operations in 1009250us (38642.6 ops/sec)
Did 34000 RSA 3072 verify (fresh key) operations in 1005116us (33826.9 ops/sec)
Did 7799 RSA 3072 private key parse operations in 1016058us (7675.7 ops/sec)
Did 276 RSA 4096 signing operations in 1008941us (273.6 ops/sec)
Did 23000 RSA 4096 verify (same key) operations in 1029290us (22345.5 ops/sec)
Did 20000 RSA 4096 verify (fresh key) operations in 1006214us (19876.5 ops/sec)
Did 5137 RSA 4096 private key parse operations in 1001233us (5130.7 ops/sec)
Did 39 RSA 8192 signing operations in 1012397us (38.5 ops/sec)
Did 6039 RSA 8192 verify (same key) operations in 1061168us (5690.9 ops/sec)
Did 5181 RSA 8192 verify (fresh key) operations in 1000616us (5177.8 ops/sec)
Did 1749 RSA 8192 private key parse operations in 1074560us (1627.6 ops/sec)
Did 6 RSA 16834 signing operations in 1147874us (5.2 ops/sec)
Did 1562 RSA 16834 verify (same key) operations in 1086732us (1437.3 ops/sec)
Did 1386 RSA 16834 verify (fresh key) operations in 1057798us (1310.3 ops/sec)
Did 440 RSA 16834 private key parse operations in 1039747us (423.2 ops/sec)
This change removes our exposure to the last of these. Also align limits
for legacy DSA and DH so that Montgomery reduction can rely on this.
Update-Note: This lowers our maximum key sizes:
- The maximum RSA modulus size is now 8,192 bits, down from 16,384 bits
- The maximum DSA p is now 8,192 bits, down from 10,000 bits
- The maximum DH p is now 8,192 bits, down from 10,000 bits
Fixed: 402677800
Change-Id: I52c0205af568b66a2fbc586b1c7300e13a47c7ab
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/80287
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This matches upstream OpenSSL. No code seems to be reaching into the
struct from what I can tell. (There also are barely any public APIs that
would make reaching into BN_MONT_CTX useful.)
Update-Note: Matching OpenSSL, BN_MONT_CTX's internals are no longer
publicly accessible.
Change-Id: I500d3e1233e21dcdbf7a0ccac8a972ac5a028742
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/80227
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
We didn't note they could be NULL in some APIs. Also almost all of EC
ignores BN_CTX anyway, so we can just say it's ignored. For the handful
of functions that don't ignore it, I think we can probably just say it
hint that you can pass in NULL and, if you think you have something
useful to do with BN_CTX, you probably know what it's used for.
(But also we should just remove the EC code's dependency on BN_CTX.
BN_CTX is really only useful when you call lots and lots of BIGNUM-using
operations in a row, and neither of the remaining such operations fall
under that umbrella.)
Bug: 42290433
Change-Id: I2766b310ca1d28a67e45354111cc2d90fa45f113
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/79988
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
EVP_PKEY_get_ec_point_conv_form comes from OpenSSL 3.x.
EVP_PKEY_get_ec_curve_nid is new because OpenSSL 3.x instead has a
string-based API.
Still a ways to go, but let's start making EVP_PKEYs more useful, so
folks don't have to dip into a parallel universe of "low-level" APIs
as much.
Bug: 42290405
Change-Id: Ide3fad08194d833a3f011116fcfb0365540e4fad
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/80009
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Update-Note: Signing RSA-PSS with the EVP APIs will now default to a
salt length of RSA_PSS_SALTLEN_DIGEST (-1) instead of
RSA_PSS_SALTLEN_AUTO (-2). Applications that use
EVP_PKEY_CTX_set_rsa_padding(RSA_PKCS1_PSS_PADDING) without calling
EVP_PKEY_CTX_set_rsa_pss_saltlen will see slightly different behavior.
Call EVP_PKEY_CTX_set_rsa_pss_saltlen(RSA_PSS_SALTLEN_AUTO) to restore
the old behavior.
The new behavior matches that protocols do in practice (TLS, our only
supported X.509 modes), and also matches FIPS 186-5 requirements. The
RSA_PSS_SALTLEN_AUTO behavior caused signing to maximize the salt
length and caused verifying to automatically recover the salt length and
accept all values. Both behaviors are forbidden by FIPS 186-5, and the
verification procedure in RFC 8017 does not admit this auto-recovery
behavior.
Change-Id: I1d5666d3401c335840d8736207143bc673d5c789
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/79987
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Honestly, we don't actually need to support hashing more than 2**64
bytes on a single machine, so we certainly don't need to support 2**128
bytes. Thus pack these structures a little better by supporting only
2**96 bytes. This removes 8 bytes from these structures and thus 24
bytes from an HMAC_CTX.
It's possible to pack SHA-512 even tighter: the final byte of the block
buffer isn't used between calls. It can be repurposed to store the
buffer length (in the lower seven bits) and an "is SHA-384" flag in the
MSB. That saves another eight bytes.
But the same trick doesn't work for BLAKE2b because it hashes in a
"final block" flag and thus needs to know whether there's more data
coming before hashing a block. Thus it uses all 128 bytes for storage.
So while we can pack SHA-512 tighter, BLAKE2b would still keep
EVP_MAX_MD_DATA_SIZE the same.
Pleasingly, this seems net-positive on benchmarks. (Or, at least, not
negative.)
Before:
Did 49145000 SHA-512 (16 bytes) operations in 5000055us (9828891.9 ops/sec): 157.3 MB/s
Did 17905000 SHA-512 (256 bytes) operations in 5000134us (3580904.0 ops/sec): 916.7 MB/s
Did 5091000 SHA-512 (1350 bytes) operations in 5000183us (1018162.7 ops/sec): 1374.5 MB/s
Did 871000 SHA-512 (8192 bytes) operations in 5004110us (174056.9 ops/sec): 1425.9 MB/s
Did 440000 SHA-512 (16384 bytes) operations in 5008994us (87842.0 ops/sec): 1439.2 MB/s
After:
Did 50435000 SHA-512 (16 bytes) operations in 5000060us (10086879.0 ops/sec): 161.4 MB/s
Did 18218000 SHA-512 (256 bytes) operations in 5000068us (3643550.4 ops/sec): 932.7 MB/s
Did 5126000 SHA-512 (1350 bytes) operations in 5000588us (1025079.5 ops/sec): 1383.9 MB/s
Did 872000 SHA-512 (8192 bytes) operations in 5002028us (174329.3 ops/sec): 1428.1 MB/s
Did 440000 SHA-512 (16384 bytes) operations in 5004069us (87928.4 ops/sec): 1440.6 MB/s
Change-Id: Ib996d82cff3e959993a9e553a688766c2e9052fb
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/79508
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Unsurprisingly, this improves benchmarks because we create a new
EVP_MD_CTX for each iteration in our speed tests.
Before:
Did 41316000 SHA-512 (16 bytes) operations in 5000013us (8263178.5 ops/sec): 132.2 MB/s
Did 16737000 SHA-512 (256 bytes) operations in 5000249us (3347233.3 ops/sec): 856.9 MB/s
Did 4991000 SHA-512 (1350 bytes) operations in 5000924us (998015.6 ops/sec): 1347.3 MB/s
Did 866000 SHA-512 (8192 bytes) operations in 5000268us (173190.7 ops/sec): 1418.8 MB/s
Did 439000 SHA-512 (16384 bytes) operations in 5003983us (87730.1 ops/sec): 1437.4 MB/s
After:
Did 49145000 SHA-512 (16 bytes) operations in 5000055us (9828891.9 ops/sec): 157.3 MB/s
Did 17905000 SHA-512 (256 bytes) operations in 5000134us (3580904.0 ops/sec): 916.7 MB/s
Did 5091000 SHA-512 (1350 bytes) operations in 5000183us (1018162.7 ops/sec): 1374.5 MB/s
Did 871000 SHA-512 (8192 bytes) operations in 5004110us (174056.9 ops/sec): 1425.9 MB/s
Did 440000 SHA-512 (16384 bytes) operations in 5008994us (87842.0 ops/sec): 1439.2 MB/s
Change-Id: If6acba87c04da716d9c7329f0595f8763827be91
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/79507
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
This function is not meaningful in BoringSSL. OpenSSL has an arbitrary
mapping from algorithms to "security levels" and offers an API to filter
TLS configuration by those levels. In OpenSSL, this function does not
return how secure |ctx| is, just what security level the caller
previously configured. As BoringSSL does not implement this API, we
return zero to report that the security levels mechanism is not used.
It is bizarre to implement a function getter without the corresponding
setter, but Python apparently wants this.
Change-Id: I0b40c9bbb2504a7a8ded28db33ece4b8535c1e7c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/79687
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
We used to pass the parent object to callbacks, but this isn't safe. The
object is in the middle of being destroyed, so the object's
invariants won't hold. We can't remove the parameters, but pass in NULL
instead.
This also has the side effect of making it possible to manage
CRYPTO_EX_DATA lifetime in its destructor, because we won't need to find
some handle back to the parent object. It also means that defensively
clearing fields in BIO destroy callbacks, while harmless, is more
obviously unnecessary.
Update-Note: CRYPTO_EX_free is no longer passed the parent object. We do
not expect any callers to be impacted. Callers that were impacted
probably had some object lifetime bug already.
Fixed: 412707574
Change-Id: Idda889898a9eca3b59e3200ba1d5b4f2e62f2d37
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/79607
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
It is (almost) no longer referenced in public headers. It still
protrudes slightly into public headers to be a parameter of CRYPTO_EX_*
callbacks. But since you cannot do anything useful with that parameter,
we can probably remove that too later.
Bug: 412269080
Change-Id: I6e2ac4d0a0868d84bb6d721d0300f5c7b2a9fe63
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/79570
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
This removes the goofy sizeof/alignof assertion we've been making. That
was a strict aliasing violation. Now CRYPTO_refcount_t is just
CRYPTO_atomic_u32 without any fuss. It also means nothing should include
<openssl/thread.h> because it contains only deprecated symbols.
Bug: 412269080
Change-Id: Icbf98a31d5af2a4dadab3b20a410c10f98061ed7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/79569
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
This does not switch our internal BIOs to the public APIs yet. The
tricky aspects are:
- We need a CRYPTO_once to fill in the BIO_METHOD, which is a little
tedious without __cxa_guard_acquire.
- bio->num is not exposed. External BIOs are expected to just make their
BIO_get_data structure more involved.
Update-Note: Callers should switch to public APIs.
Bug: 412269080
Change-Id: I09a2f61c653cf7a48412d9088e437b2bbbea3bb2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/79567
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Even the "modern" variants of the PKCS password-based private key
encryption schemes are are not very modern. We largely do not treat them
as load-bearing for security. Still, it's 2025, so we ought to upgrade
their defaults up to late 90s and early 00s cryptography.
This matches OpenSSL upstream's new behavior:
- The default MAC iteration count is 2048, not 1
- The default encryption algorithm is PBES2 with AES-256-CBC, not 3DES
and 40-bit RC2
- The PRF function for PBKDF2 inside PBES2 is HMAC-SHA256, not
HMAC-SHA1.
Update-Note: The defaults for PKCS#12 are changed as above. They match
upstream OpenSSL, so any systems compatible with OpenSSL will already be
compatible with this. The old defaults are still available by passing
them explicitly to PKCS12_create.
The one exception that OpenSSL's API does not have any way to change the
PBKDF2 PRF hash in PKCS#12. We don't anticipate this being a concern.
Note that this PRF change does not impact the old PBES1 schemes, only
the newer PBES2 schemes.
Fixed: 396434682
Change-Id: I949966483ff96796b0f76dd10b059fc98ecdeae9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/79527
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
P-224 is too small to meet our security requirements. It seems that
nothing is using this anymore, so remove it to avoid folks accidentally
turning it on when they don't mean to.
Update-Note: Attempting to configure P-224 in TLS will now fail. This
does not impact P-224 as a general cryptographic primitive. Note that
this was off by default, so unless your project was explicitly enabling
this, this will not impact you.
Change-Id: I7b931ef0f37e3fac87848a37c5173892442e4f4f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/79427
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
This appears in public headers, so we have to tolerate any warnings that
any downstream project might try to use. -Wcast-qual unfortunately seems
to be pretty unusable in C. There is no way to tell the compiler that
you actually did intentionally cast away const (here because of the type
erasure silliness we have to do to support OpenSSL's API). In C++,
const_cast works, but not in C.
So, instead, use pragmas to suppress the warning in GCC and Clang.
Fixed: 411164106
Change-Id: I37a651fb52f3049e10b7cfd3ef979ae19969c571
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/79288
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
David Benjamin