| commit | be837402a974d21071390e0d1a0ebc157901ec79 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Wed Jan 24 17:22:17 2018 -0500 |
| committer | CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> | Tue Feb 06 02:40:34 2018 +0000 |
| tree | 86cf62d4cfa4245473e73e78e1690d24763601ca | |
| parent | 150ad30d28d7d09c9efa6c1c81d77c0630abf70f [diff] |
Make the rest of RSA CRT constant-time. Alas, the existence of RSA keys with q > p is obnoxious, but we can canonicalize it away. To my knowledge, the remaining leaks in RSA are: - Key generation. This is kind of hopelessly non-constant-time but perhaps deserves a more careful ponder. Though hopefully it does not come in at a measurable point for practical purposes. - Private key serialization. RSAPrivateKey inherently leaks the magnitudes of d, dmp1, dmq1, and iqmp. This is unavoidable but hopefully does not come in at a measurable point for practical purposes. - If p and q have different word widths, we currently fall back to the variable-time BN_mod rather than Montgomery reduction at the start of CRT. I can think of ways to apply Montgomery reduction, but it's probably better to deny CRT to such keys, if not reject them outright. - bn_mul_fixed and bn_sqr_fixed which affect the Montgomery multiplication bn_mul_mont-less configurations, as well as the final CRT multiplication. We should fix this. Bug: 233 Change-Id: I8c2ecf8f8ec104e9f26299b66ac8cbb0cad04616 Reviewed-on: https://boringssl-review.googlesource.com/25263 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> 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.
There are other files in this directory which might be helpful: