| commit | 5f4f26f59c364b603c2d10ddab71ce34913284b5 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Sun Dec 07 14:53:36 2025 -0500 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Mon Dec 08 11:14:35 2025 -0800 |
| tree | 6462a85878971d1929dfe26155a5c9e504942041 | |
| parent | 21113ed83b2cd0a55e3db7a448353cbb4a1991e9 [diff] |
Retire RSA blinding support The idea to do RSA blinding dates back to one of the first papers on timing attacks in RSA in 1996. Our blinding code dates to around that time (OpenSSL git history ends at 1998). https://paulkocher.com/doc/TimingAttacks.pdf In the last 30 years, we've gained a much better understanding of side channel mitigations. In particular, blinding was added when OpenSSL's RSA implementation was very far from constant-time. BoringSSL's RSA implementation has now been constant-time for some time now, which protects against cache and timing side channels more thoroughly than blinding does. (Blinding of the base doesn't mask the exponent.) With a constant-time implementation, RSA blinding is no longer load-bearing. It is also surprisingly expensive. The mod-inverse step costs a sizeable fraction of the signing operation itself, to the point that even the original paper suggested caching the mod-inverse operation and squaring to rerandomize. This mitigation has some issues: - The blinding values are no longer independent secrets, so the mathematical grounds for the technique are shakier. - Single-use RSA keys still pay for the full inversion. - Long-lived RSA keys pay for cross-thread synchronization and cacheline contention. Given it's redundant with a constant-time RSA signing implementation, just remove it. Go's crypto/rsa package similarly dropped blinding when they became constant-time. A comparison on a Intel(R) Xeon(R) Gold 6154 CPU @ 3.00GHz: signing with single-use RSA keys decreases significantly. Multiple-use RSA keys also see a significant benefit because we remove a source of thread contention. Benchmark Time CPU Time Old Time New CPU Old CPU New ------------------------------------------------------------------------------------------------------------------------------------------ BM_SpeedRSASign/2048/threads:1 -0.0252 -0.0253 543443 529729 543420 529672 BM_SpeedRSASign/2048/threads:72 -0.1449 -0.1598 1141309 975876 1131652 950843 BM_SpeedRSAImportKeyAndSign/2048/threads:1 -0.3323 -0.3323 945512 631272 945414 631261 BM_SpeedRSAImportKeyAndSign/2048/threads:72 -0.2901 -0.3001 1567751 1112956 1515580 1060742 BM_SpeedRSASign/3072/threads:1 -0.0497 -0.0494 1731748 1645764 1731232 1645727 BM_SpeedRSASign/3072/threads:72 -0.1760 -0.1927 3590240 2958464 3540956 2858770 BM_SpeedRSAImportKeyAndSign/3072/threads:1 -0.2063 -0.2063 2391296 1897868 2390855 1897622 BM_SpeedRSAImportKeyAndSign/3072/threads:72 -0.2224 -0.2465 4213323 3276466 4092405 3083547 BM_SpeedRSASign/4096/threads:1 -0.0150 -0.0151 3715336 3659534 3714992 3658934 BM_SpeedRSASign/4096/threads:72 -0.1192 -0.0854 8024291 7067945 7647429 6994248 BM_SpeedRSAImportKeyAndSign/4096/threads:1 -0.1910 -0.1909 4905741 3968685 4904703 3968311 BM_SpeedRSAImportKeyAndSign/4096/threads:72 -0.1554 -0.1193 9182005 7755037 8483022 7471388 (Since this is the first output of the new benchmark comparison script, the time is measured in nanoseconds, and the -0.3323 means a 33.23% reduction in time per iteration.) Change-Id: I4738fb8b0539408b86faafb6ae8751aa2265f831 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/85368 Commit-Queue: David Benjamin <davidben@google.com> 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.
Project links:
To file a security issue, use the Chromium process and mention in the report this is for BoringSSL. You can ignore the parts of the process that are specific to Chromium/Chrome.
There are other files in this directory which might be helpful: