4188c3f495
The standard computation model for constant-time code is that memory access patterns must be independent of secret data. BN_mod_exp_mont_consttime was previously written to a slightly weaker model: only cacheline access patterns must be independent of secret data. It assumed accesses within a cacheline were indistinguishable. The CacheBleed attack (https://eprint.iacr.org/2016/224.pdf) showed this assumption was false. Cache lines may be divided into cache banks, and the researchers were able to measure cache bank contention pre-Haswell. For Haswell, the researchers note "But, as Haswell does show timing variations that depend on low address bits [19], it may be vulnerable to similar attacks." OpenSSL's fix to CacheBleed was not to adopt the standard constant-time computation model. Rather, it now assumes accesses within a 16-byte cache bank are indistinguishable, at least in the C copy_from_prebuf path. These weaker models failed before with CacheBleed, so avoiding such assumptions seems prudent. (The [19] citation above notes a false dependence between memory addresses with a distance of 4k, which may be what the paper was referring to.) Moreover, the C path is largely unused on x86_64 (which uses mont5 asm), so it is especially questionable for the generic C code to make assumptions based on x86_64. Just walk the entire table in the C implementation. Doing so as-is comes with a performance hit, but the striped memory layout is, at that point, useless. We regain the performance loss (and then some) by using a more natural layout. Benchmarks below. This CL does not touch the mont5 assembly; I haven't figured out what it's doing yet. Pixel 3, aarch64: Before: Did 3146 RSA 2048 signing operations in 10009070us (314.3 ops/sec) Did 447 RSA 4096 signing operations in 10026666us (44.6 ops/sec) After: Did 3210 RSA 2048 signing operations in 10010712us (320.7 ops/sec) Did 456 RSA 4096 signing operations in 10063543us (45.3 ops/sec) Pixel 3, armv7: Before: Did 2688 RSA 2048 signing operations in 10002266us (268.7 ops/sec) Did 459 RSA 4096 signing operations in 10004785us (45.9 ops/sec) After: Did 2709 RSA 2048 signing operations in 10001299us (270.9 ops/sec) Did 459 RSA 4096 signing operations in 10063737us (45.6 ops/sec) x86_64 Broadwell, mont5 assembly disabled: (This configuration is not actually shipped anywhere, but seemed a useful data point.) Before: Did 14274 RSA 2048 signing operations in 10009130us (1426.1 ops/sec) Did 2448 RSA 4096 signing operations in 10046921us (243.7 ops/sec) After: Did 14706 RSA 2048 signing operations in 10037908us (1465.0 ops/sec) Did 2538 RSA 4096 signing operations in 10059986us (252.3 ops/sec) Change-Id: If41da911d4281433856a86c6c8eadf99cd33e2d8 Reviewed-on: https://boringssl-review.googlesource.com/c/33268 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com> |
||
|---|---|---|
| .github | ||
| crypto | ||
| decrepit | ||
| fipstools | ||
| fuzz | ||
| include/openssl | ||
| infra/config | ||
| ssl | ||
| third_party | ||
| tool | ||
| util | ||
| .clang-format | ||
| .gitignore | ||
| API-CONVENTIONS.md | ||
| BREAKING-CHANGES.md | ||
| BUILDING.md | ||
| CMakeLists.txt | ||
| codereview.settings | ||
| CONTRIBUTING.md | ||
| FUZZING.md | ||
| go.mod | ||
| INCORPORATING.md | ||
| LICENSE | ||
| PORTING.md | ||
| README.md | ||
| sources.cmake | ||
| STYLE.md | ||
BoringSSL
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:
- PORTING.md: how to port OpenSSL-using code to BoringSSL.
- BUILDING.md: how to build BoringSSL
- INCORPORATING.md: how to incorporate BoringSSL into a project.
- API-CONVENTIONS.md: general API conventions for BoringSSL consumers and developers.
- STYLE.md: rules and guidelines for coding style.
- include/openssl: public headers with API documentation in comments. Also available online.
- FUZZING.md: information about fuzzing BoringSSL.
- CONTRIBUTING.md: how to contribute to BoringSSL.
- BREAKING-CHANGES.md: notes on potentially-breaking changes.