On Tue, 18 Aug 2020 at 10:24, Herbert Xu <herb...@gondor.apana.org.au> wrote: > > On Sun, Aug 02, 2020 at 12:06:16PM +0300, Ard Biesheuvel wrote: > > Ben reports that CCM using AES-NI instructions performs pathologically > > poorly, which is due to the overhead of preserving/restoring the SIMD > > state, which is repeated after every 16 bytes of input when executing > > the CBCMAC portion of the algorithm. > > > > So let's clone the arm64 implementation of cbcmac(aes), which takes > > care to only preserve/restore the SIMD state after processing the > > whole input. Since cmac(aes) and xcbc(aes) can reuse most of the code, > > let's expose those as well. > > > > Cc: Ben Greear <gree...@candelatech.com> > > Signed-off-by: Ard Biesheuvel <a...@kernel.org> > > --- > > arch/x86/crypto/Makefile | 2 +- > > arch/x86/crypto/aesni-intel.h | 39 +++ > > arch/x86/crypto/aesni-intel_glue.c | 42 +--- > > arch/x86/crypto/aesni-intel_mac.c | 257 ++++++++++++++++++++ > > 4 files changed, 306 insertions(+), 34 deletions(-) > > We should just use the accelerated cbc skcipher. >
What do you mean? You cannot implement cbcmac using a cbc skcipher unless you provide a scratch buffer of arbitrary size as the destination, in order to capture the skcipher output IV as the MAC.
