|author||David Benjamin <firstname.lastname@example.org>||Fri Feb 09 15:52:58 2018 -0500|
|committer||CQ bot account: email@example.com <firstname.lastname@example.org>||Fri Feb 09 22:17:11 2018 +0000|
Fix threading issues with RSA freeze_private_key. OpenSSL's RSA API is poorly designed and does not have a single place to properly initialize the key. See https://github.com/openssl/openssl/issues/5158. To workaround this flaw, we must lazily instantiate pre-computed Montgomery bits with locking. This is a ton of complexity. More importantly, it makes it very difficult to implement RSA without side channels. The correct in-memory representation of d, dmp1, and dmq1 depend on n, p, and q, respectively. (Those values have private magnitudes and must be sized relative to the respective moduli.) 08805fe27910e09d05e87d61bc5411a4e3b2d999 attempted to fix up the various widths under lock, when we set up BN_MONT_CTX. However, this introduces threading issues because other threads may access those exposed components (RSA_get0_* also count as exposed for these purposes because they are get0 functions), while a private key operation is in progress. Instead, we do the following: - There is no actual need to minimize n, p, and q, but we have minimized copies in the BN_MONT_CTXs, so use those. - Store additional copies of d, dmp1, and dmq1, at the cost of more memory used. These copies have the correct width and are private, unlike d, dmp1, and dmq1 which are sadly exposed. Fix private key operations to use them. - Move the frozen bit out of rsa->flags, as that too was historically accessible without locking. (Serialization still uses the original BIGNUMs, but the RSAPrivateKey serialization format already inherently leaks the magnitude, so this doesn't matter.) Change-Id: Ia3a9b0629f8efef23abb30bfed110d247d1db42f Reviewed-on: https://boringssl-review.googlesource.com/25824 Commit-Queue: David Benjamin <email@example.com> CQ-Verified: CQ bot account: firstname.lastname@example.org <email@example.com> Reviewed-by: Adam Langley <firstname.lastname@example.org>
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: