| commit | 21f694210c9232d6ab926d029c315ae6069c7dbb | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Tue Apr 21 19:14:37 2020 -0400 |
| committer | CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> | Thu Apr 23 21:31:07 2020 +0000 |
| tree | 1cf9e94e16c7d951676825cd968203c56973d06e | |
| parent | 47b1e39042bc3208771a8d947f1a1ed2fe5f3d8b [diff] |
Use faster addition chains for P-256 field inversion. Switch to the addition chains by Brian Smith in https://briansmith.org/ecc-inversion-addition-chains-01#p256_field_inversion The new addition chains are a bit faster when measured independently. They aren't, however, noticeable when measured with everything else in ECDH. Rather, the motivation is just to align fiat_p256, nistz256, and a possible future fiat_p384 import. Since it's free, I've included the (negligible) z^-2 optimization, but if we ever want a z^-1 abstraction, it doesn't actually matter. In the meantime, it replaces the (even more negligible) Montgomery conversion optimization which is a bit less odd on the EC_FELEM abstraction. (I'm pondering whether we want an EC_AFFINE abstraction given how the Trust Tokens DLEQ proofs work.) fiat_p256 (64-bit): Before: Did 539000 P-256 get x operations in 5007148us (107646.1 ops/sec) Did 532000 P-256 get x and y operations in 5008736us (106214.4 ops/sec) After: Did 607000 P-256 get x operations in 5005225us (121273.3 ops/sec) Did 594000 P-256 get x and y operations in 5001251us (118770.3 ops/sec) nistz256: Before: Did 1472000 P-256 get x operations in 5003286us (294206.6 ops/sec) Did 1445000 P-256 get x and y operations in 5002052us (288881.4 ops/sec) After: Did 1491000 P-256 get x operations in 5002524us (298049.5 ops/sec) Did 1452000 P-256 get x and y operations in 5003193us (290214.7 ops/sec) I haven't bothered checking in the benchmarks as those operations standalone are largely artificial. They're a consequence of using the same type for affine and Jacobian points. Change-Id: I71e0d50a8712198f9cb8f68d50894d14a6091635 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40867 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@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.
Project links:
There are other files in this directory which might be helpful: