33f456b8b0
RAND_bytes rarely uses large enough inputs for bsaes to be worth it. https://boringssl-review.googlesource.com/c/boringssl/+/33589 includes some rough benchmarks of various bits here. Some observations: - 8 blocks of bsaes costs roughly 6.5 blocks of vpaes. Note the comparison isn't quite accurate because I'm measuring bsaes_ctr32_encrypt_blocks against vpaes_encrypt and vpaes in CTR mode today must make do with a C loop. Even assuming a cutoff of 6 rather than 7 blocks, it's rare to ask for 96 bytes of entropy at a time. - CTR-DRBG performs some stray block operations (ctr_drbg_update), which bsaes is bad at without extra work to fold them into the CTR loop (not really worth it). - CTR-DRBG calculates a couple new key schedules every RAND_bytes call. We don't currently have a constant-time bsaes key schedule. Unfortunately, even plain vpaes loses to the current aes_nohw used by bsaes, but it's not constant-time. Also taking CTR-DRBG out of the bsaes equation - Machines without AES hardware (clients) are not going to be RNG-bound. It's mostly servers pushing way too many CBC IVs that care. This means bsaes's current side channel tradeoffs make even less sense here. I'm not sure yet what we should do for the rest of the bsaes mess, but it seems clear that we want to stick with vpaes for the RNG. Bug: 256 Change-Id: Iec8f13af232794afd007cb1065913e8117eeee24 Reviewed-on: https://boringssl-review.googlesource.com/c/34744 Reviewed-by: Adam Langley <agl@google.com> |
||
|---|---|---|
| .github | ||
| crypto | ||
| decrepit | ||
| fipstools | ||
| fuzz | ||
| include/openssl | ||
| 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.