tree b499cd313e59faab9028cf16bc9bf6c911fa0229
parent da8bb847fd9aa9b029bf0383cbe0de9796495c1a
author David Benjamin <davidben@google.com> 1551574438 -0600
committer Adam Langley <agl@google.com> 1551808503 +0000

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>