CMAC timings

Kurt Roeckx kurt at roeckx.be
Thu Jun 18 17:24:39 UTC 2020


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



More information about the openssl-users mailing list