| commit | 96c24252244ef72967cc052bbbcafacb4509a87a | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Wed Aug 13 17:54:15 2025 -0400 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Thu Aug 28 10:03:48 2025 -0700 |
| tree | 4194a75e226597e9a66b00c93249ff7c063bc783 | |
| parent | b402cff383c5d150bc69d9c5c0d9288d718caf5b [diff] |
Introduce EVP_PKEY_ALG 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>
BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.
Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.
Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.
BoringSSL arose because Google used OpenSSL for many years in various ways and, over time, built up a large number of patches that were maintained while tracking upstream OpenSSL. As Google's product portfolio became more complex, more copies of OpenSSL sprung up and the effort involved in maintaining all these patches in multiple places was growing steadily.
Currently BoringSSL is the SSL library in Chrome/Chromium, Android (but it's not part of the NDK) and a number of other apps/programs.
Project links:
To file a security issue, use the Chromium process and mention in the report this is for BoringSSL. You can ignore the parts of the process that are specific to Chromium/Chrome.
There are other files in this directory which might be helpful: