| commit | d319205007c10ca27280496b2de9d7256dbd953d | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Fri Jan 26 17:22:27 2018 -0500 |
| committer | CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> | Tue Apr 17 15:14:04 2018 +0000 |
| tree | daa208917c92ed2077a55cdbf0f2eedc84b581fd | |
| parent | 024f5df3c861357873817cef6b39db94c83e239f [diff] |
Deny CRT to unbalanced RSA keys. Our technique to perform the reduction only works for balanced key sizes. For unbalanced keys, we fall back to variable-time logic. Instead, fall back earlier to the non-CRT codepath, which is still secure, just slower. This also aligns with the advice here: https://github.com/HACS-workshop/spectre-mitigations/blob/master/crypto_guidelines.md#1-do-not-conditionally-choose-between-constant-and-non-constant-time Update-Note: This is a performance hit (some keys will run 3x slower), but only for keys with different-sized primes. I believe the Windows crypto APIs will not accept such keys at all. There are two scenarios to be concerned with for RSA performance: 1. Performance of reasonably-generated keys. Keys that BoringSSL or anyone else reasonable generates will all be balanced, so this change does not affect them. 2. Worst-case performance for DoS purposes. This CL does not change the worst-case performance for RSA at a given bit size. In fact, it improves it slightly. A sufficiently unbalanced RSA key is as slow as not doing CRT at all. In both cases, this change does not affect performance. The affected keys are pathologically-generated ones that were not quite pathological enough. Bug: 235 Change-Id: Ie298dabb549ab9108fa9374aa86ebffe8b6c6c88 Reviewed-on: https://boringssl-review.googlesource.com/27504 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.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: