Revert "Replace aes_nohw with a bitsliced implementation."

This reverts commit b3ac6bb39ad3f980dccae24dfacd97b6e3e57391.

Reason for revert: 32-bit version seems to be broken. I'll debug this
and improve pre-commit CQ coverage before relanding.

Original change's description:
> Replace aes_nohw with a bitsliced implementation.
> 
> aes_nohw is currently one of several variable-time table-based
> implementations in C or assembly (armv4, x86, and x86_64). Replace all
> of these with a C bitsliced implementation, with 32-bit, 64-bit, and
> 128-bit (SSE2) variants. This is based on the algorithms described in:
> 
> https://bearssl.org/constanttime.html#aes
> https://eprint.iacr.org/2009/129.pdf
> https://eprint.iacr.org/2009/191.pdf
> 
> This makes our AES implementation constant-time in all build
> configurations!
> 
> There were far too many benchmarks to put in the commit message.
> Instead, please refer to this fancy spreadsheet:
> https://docs.google.com/spreadsheets/d/1wDCzfkPl7brfjWJKq55awQjwCPhOYI8O7zSQZuEc2Xg/edit?usp=sharing
> 
> Parallel modes on x86 and x86_64 do fine due to the SSE2 code. AES-GCM
> actually gets faster. The 64-bit (4x) bitsliced implementation is less
> effective at speeding parallel modes but still helps. The 32-bit (2x)
> bitsliced implementation even less.
> 
> Non-parallel modes, sadly, take a *dramatic* performance hit. I tried a
> constant-time table lookup for comparison, but bitslicing was still
> better. This implementation performs comparably to the table in
> BearSSL's documentation, which suggests I didn't do anything obviously
> wrong. (Note BearSSL's table for 'ct' corresponds to a 32-bit bitsliced
> implementation compiled for 64-bit. Compiling this implementation for
> 64-bit matches, but compiling it for 32-bit seems to be considerably
> slower.)
> 
> Assumptions that may make this palatable:
> 
> - AES-GCM is by far the most important AES mode, and we perform okay
>   with it. Modern things aren't built out of CBC.
> 
> - A nontrivial chunk of Chrome users on Windows don't have SSSE3 and
>   would be affected by this change. They would get the SSE2 version
>   which performs well for AES-GCM *and* is constant-time.
> 
> - ARM devices are primarily mobile which cycles hardware much faster.
>   Chrome for Android has required NEON for several years now, so it
>   would not run this code. (Aside from https://crbug.com/341598.)
> 
> - aarch64 mandates NEON, so it would not run this code.
> 
> - QUIC packet number encryption does use a one-off block operation, but
>   only once per packet.
> 
> - Arguably this is undoing a performance gain that we never earned. That
>   said, it was a dramatic performance gain in places.
> 
> As an alternative, we could just check in the SSE2 version and drop the
> x86 and x86_64 table-based assembly, but this still leaves the generic
> code with cache-timing side channels.
> 
> Change-Id: I0f4b4467a49790509503c529d7c0940318096a00
> Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39206
> Commit-Queue: Adam Langley <agl@google.com>
> Reviewed-by: Adam Langley <agl@google.com>

TBR=agl@google.com,davidben@google.com

Change-Id: Iffaf01a98ab40bbfa009c451aa20ba3eb923eab9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39285
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
12 files changed
tree: 61f95376e521444e93951d3e2eee5ad00b2347a0
  1. .clang-format
  2. .github/
  3. .gitignore
  4. API-CONVENTIONS.md
  5. BREAKING-CHANGES.md
  6. BUILDING.md
  7. CMakeLists.txt
  8. CONTRIBUTING.md
  9. FUZZING.md
  10. INCORPORATING.md
  11. LICENSE
  12. PORTING.md
  13. README.md
  14. STYLE.md
  15. codereview.settings
  16. crypto/
  17. decrepit/
  18. fuzz/
  19. go.mod
  20. include/
  21. sources.cmake
  22. ssl/
  23. third_party/
  24. tool/
  25. util/
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:

There are other files in this directory which might be helpful: