| commit | e6f46e2563904ce47fd5de667d10628d560206c5 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Sun Feb 04 23:48:36 2018 -0500 |
| committer | CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> | Thu Mar 29 22:02:24 2018 +0000 |
| tree | e6ea5fb4fa88a60b5f0610b67551bea1a0af0bb6 | |
| parent | 8eadca50a22af8a971220035e85beecf423a5e51 [diff] |
Blind the range check for finding a Rabin-Miller witness. Rabin-Miller requires selecting a random number from 2 to |w|-1. This is done by picking an N-bit number and discarding out-of-range values. This leaks information about |w|, so apply blinding. Rather than discard bad values, adjust them to be in range. Though not uniformly selected, these adjusted values are still usable as Rabin-Miller checks. Rabin-Miller is already probabilistic, so we could reach the desired confidence levels by just suitably increasing the iteration count. However, to align with FIPS 186-4, we use a more pessimal analysis: we do not count the non-uniform values towards the iteration count. As a result, this function is more complex and has more timing risk than necessary. We count both total iterations and uniform ones and iterate until we've reached at least |BN_PRIME_CHECKS_BLINDED| and |iterations|, respectively. If the latter is large enough, it will be the limiting factor with high probability and we won't leak information. Note this blinding does not impact most calls when picking primes because composites are rejected early. Only the two secret primes see extra work. So while this does make the BNTest.PrimeChecking test take about 2x longer to run on debug mode, RSA key generation time is fine. Another, perhaps simpler, option here would have to run bn_rand_range_words to the full 100 count, select an arbitrary successful try, and declare failure of the entire keygen process (as we do already) if all tries failed. I went with the option in this CL because I happened to come up with it first, and because the failure probability decreases much faster. Additionally, the option in this CL does not affect composite numbers, while the alternate would. This gives a smaller multiplier on our entropy draw. We also continue to use the "wasted" work for stronger assurance on primality. FIPS' numbers are remarkably low, considering the increase has negligible cost. Thanks to Nathan Benjamin for helping me explore the failure rate as the target count and blinding count change. Now we're down to the rest of RSA keygen, which will require all the operations we've traditionally just avoided in constant-time code! Median of 29 RSA keygens: 0m0.169s -> 0m0.298s (Accuracy beyond 0.1s is questionable. The runs at subsequent test- and rename-only CLs were 0m0.217s, 0m0.245s, 0m0.244s, 0m0.247s.) Bug: 238 Change-Id: Id6406c3020f2585b86946eb17df64ac42f30ebab Reviewed-on: https://boringssl-review.googlesource.com/25890 Commit-Queue: Adam Langley <agl@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: