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
