73535ab252
This one is a little thorny. All the various block cipher modes functions and callbacks take a void *key. This allows them to be used with multiple kinds of block ciphers. However, the implementations of those callbacks are the normal typed functions, like AES_encrypt. Those take AES_KEY *key. While, at the ABI level, this is perfectly fine, C considers this undefined behavior. If we wish to preserve this genericness, we could either instantiate multiple versions of these mode functions or create wrappers of AES_encrypt, etc., that take void *key. The former means more code and is tedious without C++ templates (maybe someday...). The latter would not be difficult for a compiler to optimize out. C mistakenly allowed comparing function pointers for equality, which means a compiler cannot replace pointers to wrapper functions with the real thing. (That said, the performance-sensitive bits already act in chunks, e.g. ctr128_f, so the function call overhead shouldn't matter.) But our only 128-bit block cipher is AES anyway, so I just switched things to use AES_KEY throughout. AES is doing fine, and hopefully we would have the sense not to pair a hypothetical future block cipher with so many modes! Change-Id: Ied3e843f0e3042a439f09e655b29847ade9d4c7d Reviewed-on: https://boringssl-review.googlesource.com/32107 Reviewed-by: Adam Langley <agl@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.