|author||David Benjamin <email@example.com>||Wed Jan 24 15:29:00 2018 -0500|
|committer||CQ bot account: firstname.lastname@example.org <email@example.com>||Tue Feb 06 01:16:04 2018 +0000|
Make BN_mod_*_quick constant-time. As the EC code will ultimately want to use these in "words" form by way of EC_FELEM, and because it's much easier, I've implement these as low-level words-based functions that require all inputs have the same width. The BIGNUM versions which RSA and, for now, EC calls are implemented on top of that. Unfortunately, doing such things in constant-time and accounting for undersized inputs requires some scratch space, and these functions don't take BN_CTX. So I've added internal bn_mod_*_quick_ctx functions that take a BN_CTX and the old functions now allocate a bit unnecessarily. RSA only needs lshift (for BN_MONT_CTX) and sub (for CRT), but the generic EC code wants add as well. The generic EC code isn't even remotely constant-time, and I hope to ultimately use stack-allocated EC_FELEMs, so I've made the actual implementations here implemented in "words", which is much simpler anyway due to not having to take care of widths. I've also gone ahead and switched the EC code to these functions, largely as a test of their performance (an earlier iteration made the EC code noticeably slower). These operations are otherwise not performance-critical in RSA. The conversion from BIGNUM to BIGNUM+BN_CTX should be dropped by the static linker already, and the unused BIGNUM+BN_CTX functions will fall off when EC_FELEM happens. Update-Note: BN_mod_*_quick bounce on malloc a bit now, but they're not really used externally. The one caller I found was wpa_supplicant which bounces on malloc already. They appear to be implementing compressed coordinates by hand? We may be able to convince them to call EC_POINT_set_compressed_coordinates_GFp. Bug: 233, 236 Change-Id: I2bf361e9c089e0211b97d95523dbc06f1168e12b Reviewed-on: https://boringssl-review.googlesource.com/25261 Commit-Queue: David Benjamin <firstname.lastname@example.org> CQ-Verified: CQ bot account: email@example.com <firstname.lastname@example.org> Reviewed-by: Adam Langley <email@example.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.
There are other files in this directory which might be helpful: