| commit | b8d7b7498c2d198ceef431ae2869bcc3acd43a74 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Sat Mar 02 18:53:58 2019 -0600 |
| committer | Adam Langley <agl@google.com> | Tue Mar 05 17:55:03 2019 +0000 |
| tree | b499cd313e59faab9028cf16bc9bf6c911fa0229 | |
| parent | da8bb847fd9aa9b029bf0383cbe0de9796495c1a [diff] |
Prefer vpaes over bsaes in AES-GCM-SIV and AES-CCM. The AES-GCM-SIV code does not use ctr128_f at all so bsaes is simply identical to aes_nohw. Also, while CCM encrypts with CTR mode, its MAC is not parallelizable at all. (Given the existence of non-parallelizable modes, we ought to make a vpaes-armv7.pl to ensure constant-time AES on NEON. For now, pick the right implementation for x86_64 at least.) aes_ctr_set_key and friends probably aren't the right abstraction (observe the large vs small inputs hint *almost* matches whether you touch block128_f), but the right abstraction depends on a couple questions: - If you don't provide ctr128_f, is there a perf hit to implementing ctr128_f on top of your block128_f to unify calling code? - It is almost certainly better to use bsaes with gcm.c by calling ctr128_f exclusively and paying some copies (a dedicated calling convention would be even better, but would be a headache) to integrate leading and trailing blocks into the CTR pass. Is this a win, loss, or no-op for hwaes, where block128_f is just fine? hwaes is the one mode we really should not regress. Hopefully those will get answered as we continue to chip away at this. Bug: 256 Change-Id: I8f0150b223b671e68f7da6faaff94a3bea398d4d Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35169 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.
There are other files in this directory which might be helpful: