CMAC timings

[Kurt Roeckx]

On Thu, Jun 18, 2020 at 02:12:56PM +0000, Blumenthal, Uri - 0553 - MITLL wrote:
> I think that the default behavior should change for 3.0, and the API change described in the Release Notes. I find that alternative less impacting that this silent sudden performance deterioration.

Note that I was just looking at why the EVP PKEY API was slow, and
the first thing I found was the EVP_MD_CTX_FLAG_FINALISE's impact.
This also has a big impact in the 1.1.1 version:
CMAC API:
     AES-128  16 48 16    410   0.410  475ac1c053379e7dbd4ce80b87d2178e
EVP_PKEY:
     AES-128  16 48 16    739   0.739  475ac1c053379e7dbd4ce80b87d2178e
EVP_PKEY adding EVP_MD_CTX_FLAG_FINALISE:
     AES-128  16 48 16    291   0.291  475ac1c053379e7dbd4ce80b87d2178e

The same with AESNI disabled:
CMAC API:
     AES-128  16 48 16    584   0.584  475ac1c053379e7dbd4ce80b87d2178e
EVP_PKEY:
     AES-128  16 48 16    823   0.823  475ac1c053379e7dbd4ce80b87d2178e
EVP_PKEY adding EVP_MD_CTX_FLAG_FINALISE:
     AES-128  16 48 16    387   0.387  475ac1c053379e7dbd4ce80b87d2178e

Now that a large fraction of the cost has been found, I can look
again to see where the biggest cost in 3.0 comes from now and if we
can do something about it.

I think changing the default is going to break applications, which
is what we want to avoid. I think we should document that this can
overhead can be large if you do small packets and that the
behavioru can be changed with that option.


Kurt