| commit | 48b1f45203f64e2c273736ef2deaef7bb0fa7095 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Wed Mar 12 13:44:53 2025 -0400 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Sat Mar 15 09:52:07 2025 -0700 |
| tree | 3dfe043d91d48b9c8f8f71221807ef5f727b8c48 | |
| parent | a71d28876b4afd400ba4bbd997b3db72bcd3405c [diff] |
Decrease BN_MONTGOMERY_MAX_WORDS to 16384 bits I'm not sure where I got the original value (I think it was when I was trying to set a limit for all of BIGNUM) but 8 KiB is still a fairly large stack allocation. I also missed that some of the bn_mul_mont implementations seem to alloca 2 * num words, so that's actually 16 KiB of stack used. We only support up to 16384-bit RSA, so we only need BN_MONT_CTX to work with that. Lower the limit accordingly. Ideally we'd get down to 8192 (see crbug.com/402677800). While we have to allow giant BIGNUMs for some non-cryptography callers, this means that Montgomery reduction and all the cryptography code can assume one integer fits in 2 KiB (lowering the RSA limit could bring us down to 1 KiB). I'm hoping this is small enough that all our Montgomery multiplication codepaths can just stack-allocate their temporaries. (We already believe it's small enough for bn_mul_mont, just other codepaths still allocate.) That should remove the main load-bearing use of BN_CTX. Update-Note: BN_MONT_CTX now only works for 16834-bit moduli or lower. This has no impact on cryptographic primitives supported by BoringSSL, which were already capped at that size. Bug: 42290433, 402677800 Change-Id: Iaaf8ba34eabeb3b90f4219e0faa5b74c4b1de4b8 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/77507 Reviewed-by: Bob Beck <bbe@google.com> Auto-Submit: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@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: