| commit | eda47f5d98d46cca612152c648ad98c74619d946 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Sun Apr 01 14:31:44 2018 -0400 |
| committer | CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> | Wed Apr 04 21:33:22 2018 +0000 |
| tree | acd09c83b0c74dbae009edc2b98de1fe234d99d6 | |
| parent | 56986f905f973d478b0ba44ccdc569be0074d5fb [diff] |
Make generic point arithmetic slightly less variable-time. The generic code special-cases affine points, but this leaks information. (Of course, the generic code also doesn't have a constant-time multiply and other problems, but one thing at a time.) The optimization in point doubling is not useful. Point multiplication more-or-less never doubles an affine point. The optimization in point addition *is* useful because the wNAF code converts the tables to affine. Accordingly, align with the P-256 code which adds a 'mixed' parameter. (I haven't aligned the formally-verified point formulas themselves yet; initial testing suggests that the large number of temporaries take a perf hit with BIGNUM. I'll check the results in EC_FELEM, which will be stack-allocated, to see if we still need to help the compiler out.) Strangly, it actually got a bit faster with this change. I'm guessing because now it doesn't need to bother with unnecessary comparisons and maybe was kinder to the branch predictor? Before: Did 2201 ECDH P-384 operations in 3068341us (717.3 ops/sec) Did 4092 ECDSA P-384 signing operations in 3076981us (1329.9 ops/sec) Did 3503 ECDSA P-384 verify operations in 3024753us (1158.1 ops/sec) Did 992 ECDH P-521 operations in 3017884us (328.7 ops/sec) Did 1798 ECDSA P-521 signing operations in 3059000us (587.8 ops/sec) Did 1581 ECDSA P-521 verify operations in 3033142us (521.2 ops/sec) After: Did 2310 ECDH P-384 operations in 3092648us (746.9 ops/sec) Did 4080 ECDSA P-384 signing operations in 3044588us (1340.1 ops/sec) Did 3520 ECDSA P-384 verify operations in 3056070us (1151.8 ops/sec) Did 992 ECDH P-521 operations in 3012779us (329.3 ops/sec) Did 1792 ECDSA P-521 signing operations in 3019459us (593.5 ops/sec) Did 1600 ECDSA P-521 verify operations in 3047749us (525.0 ops/sec) Bug: 239 Change-Id: If5d13825fc98e4c58bdd1580cf0245bf7ce93a82 Reviewed-on: https://boringssl-review.googlesource.com/27004 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: