| commit | d5f3a9e82fc6735eff5733f51b892d776f4a84eb | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Tue Apr 25 18:01:14 2023 -0400 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Tue Apr 25 23:07:53 2023 +0000 |
| tree | ac9e839e0bc970005b65547cc0a63749edcb8685 | |
| parent | 4b6d950d8921d6dd5365de0797fcc97302b9561b [diff] |
Squeeze a block at a time when computing the matrix in Kyber We were currently squeezing 3 bytes at a time. And because kyber.c and keccak.c are separate files, we've got an optimization barrier, at least in non-LTO builds, at a very inconvenient place. Instead, extract the full 168 bytes (SHAKE-128 rate) at a time. This is conveniently a multiple of three, so we don't need to worry about partial coefficients. We're still doing a copy due to the Keccak abstraction, but it should extend cleanly to either LTO or a different abstraction to read from the state directly. Even without that, it's a significant perf win. Benchmarks on an M1: Before: Did 87390 Kyber generate + decap operations in 4001590us (21838.8 ops/sec) Did 119000 Kyber parse + encap operations in 4009460us (29679.8 ops/sec) After: Did 96747 Kyber generate + decap operations in 4003687us (24164.5 ops/sec) [+10.6%] Did 152000 Kyber parse + encap operations in 4018360us (37826.4 ops/sec) [+27.4%] Change-Id: Iada393edf0c634b7410a34374fb90242a392a9d3 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59265 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com> Auto-Submit: 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: