b6473199a3
On 32-bit x86, |bn_mul_mont| returns 0 when the modulus has less than four limbs. Instead of calling |bn_mul_mont| and then falling back to the |BN_mul|+|BN_from_montgomery_word| path for small moduli, just avoid calling |bn_mul_mont| at all for small moduli. This allows us to more clearly understand exactly when the fallback code path, which is a timing side channel, is taken. This change makes it easier to start minimizing this side channel. The limit is set at 128 bits, which is four limbs on 32-bit and two limbs on 64-bit platforms. Do this consistently on all platforms even though it seems to be needed only for 32-bit x86, to minimize platform variance: every platform uses the same cut-off in terms of input size. 128 bits is small enough to allow even questionably small curves, like secp128r1, to use the |bn_mul_mont| path, and is way too small for RSA and FFDH, so this change shouldn't have any security impact other than the positive impact of simplifying the control flow. Change-Id: I9b68ae33dc2c86b54ed4294839c7eca6a1dc11c0 Reviewed-on: https://boringssl-review.googlesource.com/14084 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> |
||
|---|---|---|
| .github | ||
| crypto | ||
| decrepit | ||
| fuzz | ||
| include/openssl | ||
| infra/config | ||
| ssl | ||
| third_party | ||
| tool | ||
| util | ||
| .clang-format | ||
| .gitignore | ||
| API-CONVENTIONS.md | ||
| BUILDING.md | ||
| CMakeLists.txt | ||
| codereview.settings | ||
| CONTRIBUTING.md | ||
| FUZZING.md | ||
| INCORPORATING.md | ||
| LICENSE | ||
| PORTING.md | ||
| README.md | ||
| STYLE.md | ||
BoringSSL
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.
There are other files in this directory which might be helpful:
- PORTING.md: how to port OpenSSL-using code to BoringSSL.
- BUILDING.md: how to build BoringSSL
- INCORPORATING.md: how to incorporate BoringSSL into a project.
- API-CONVENTIONS.md: general API conventions for BoringSSL consumers and developers.
- STYLE.md: rules and guidelines for coding style.
- include/openssl: public headers with API documentation in comments. Also available online.
- FUZZING.md: information about fuzzing BoringSSL.
- CONTRIBUTING.md: how to contribute to BoringSSL.