Google Git
Sign in
boringssl / boringssl / fa69468414cedfab3ced42426df5920f9b2c345f
commitfa69468414cedfab3ced42426df5920f9b2c345f[log] [tgz]
authorDavid Benjamin <davidben@google.com>Fri Dec 13 18:13:02 2024 -0500
committerBoringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com>Sat Dec 14 15:15:18 2024 -0800
tree2aa6b40302032fb201681c27a4cdad28c59354b9
parent0436a33c875ead926d821b12075fd20d47b6bc77 [diff]
Always provide a ctr32_encrypt_blocks function

There were two places where the ctr32_encrypt_blocks function could be
missing:

1. In the AES-CTR EVP_CIPHER, with aes_nohw, we forgot to fill it in but
   we actually provide it. We don't care enough about AES-CTR to
   benchmark it, but I expect this to be a significant perf win because
   aes_nohw is bitsliced.

2. The 32-bit x86 vpaes implementation did not have a
   ctr32_encrypt_blocks. Just implement it in C.

This allows us to delete a ton of code for a broadly unreachable
codepath.

32-bit x86 is not a particularly important target in 2024, but just to
confirm, here is the impact on AES-GCM on an Intel(R) Xeon(R) Gold 6154
CPU @ 3.00GHz, running in 32-bit mode and with
OPENSSL_ia32cap='~0x200000000000000'

Before:
Did 5587000 AES-128-GCM (16 bytes) seal operations in 1000098us (5586452.5 ops/sec): 89.4 MB/s
Did 1063000 AES-128-GCM (256 bytes) seal operations in 1000036us (1062961.7 ops/sec): 272.1 MB/s
Did 225000 AES-128-GCM (1350 bytes) seal operations in 1001725us (224612.5 ops/sec): 303.2 MB/s
Did 39000 AES-128-GCM (8192 bytes) seal operations in 1014011us (38461.1 ops/sec): 315.1 MB/s
Did 19127 AES-128-GCM (16384 bytes) seal operations in 1009808us (18941.2 ops/sec): 310.3 MB/s
Did 4742000 AES-256-GCM (16 bytes) seal operations in 1000051us (4741758.2 ops/sec): 75.9 MB/s
Did 820000 AES-256-GCM (256 bytes) seal operations in 1000199us (819836.9 ops/sec): 209.9 MB/s
Did 171000 AES-256-GCM (1350 bytes) seal operations in 1000656us (170887.9 ops/sec): 230.7 MB/s
Did 30000 AES-256-GCM (8192 bytes) seal operations in 1034187us (29008.3 ops/sec): 237.6 MB/s
Did 15000 AES-256-GCM (16384 bytes) seal operations in 1031233us (14545.7 ops/sec): 238.3 MB/s
After:
Did 5314000 AES-128-GCM (16 bytes) seal operations in 1000040us (5313787.4 ops/sec): 85.0 MB/s
Did 1035000 AES-128-GCM (256 bytes) seal operations in 1000919us (1034049.7 ops/sec): 264.7 MB/s
Did 220000 AES-128-GCM (1350 bytes) seal operations in 1001498us (219670.9 ops/sec): 296.6 MB/s
Did 37000 AES-128-GCM (8192 bytes) seal operations in 1009332us (36657.9 ops/sec): 300.3 MB/s
Did 19000 AES-128-GCM (16384 bytes) seal operations in 1018435us (18656.1 ops/sec): 305.7 MB/s
Did 4512250 AES-256-GCM (16 bytes) seal operations in 1000047us (4512037.9 ops/sec): 72.2 MB/s
Did 803000 AES-256-GCM (256 bytes) seal operations in 1000917us (802264.3 ops/sec): 205.4 MB/s
Did 168000 AES-256-GCM (1350 bytes) seal operations in 1002181us (167634.4 ops/sec): 226.3 MB/s
Did 29000 AES-256-GCM (8192 bytes) seal operations in 1033945us (28047.9 ops/sec): 229.8 MB/s
Did 15000 AES-256-GCM (16384 bytes) seal operations in 1055312us (14213.8 ops/sec): 232.9 MB/s

It's a bit slower, but comparable. Any affected device should really be
served ChaCha20-Poly1305 anyway. (Of course, this is entirely
unscientific because this code would never run on anything remotely like
this CPU.)

Fixed: 383994657
Change-Id: Ifca6a6195b20497dc7053d736c61b9000d3074f9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74267
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
12 files changed
tree: 2aa6b40302032fb201681c27a4cdad28c59354b9
  1. .bcr/
  2. .github/
  3. cmake/
  4. crypto/
  5. decrepit/
  6. docs/
  7. fuzz/
  8. gen/
  9. include/
  10. infra/
  11. pki/
  12. rust/
  13. ssl/
  14. third_party/
  15. tool/
  16. util/
  17. .bazelignore
  18. .bazelrc
  19. .bazelversion
  20. .clang-format
  21. .gitignore
  22. API-CONVENTIONS.md
  23. AUTHORS
  24. BREAKING-CHANGES.md
  25. BUILD.bazel
  26. build.json
  27. BUILDING.md
  28. CMakeLists.txt
  29. codereview.settings
  30. CONTRIBUTING.md
  31. FUZZING.md
  32. go.mod
  33. go.sum
  34. INCORPORATING.md
  35. LICENSE
  36. MODULE.bazel
  37. MODULE.bazel.lock
  38. PORTING.md
  39. PrivacyInfo.xcprivacy
  40. README.md
  41. SANDBOXING.md
  42. STYLE.md
README.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.

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: