CMAC timings

[Kurt Roeckx]

On Wed, Jun 17, 2020 at 03:50:05AM -0700, Hal Murray wrote:
> levitte at openssl.org said:
> > What does surprise me, though, is that direct EVP_MAC calls would be slower
> > than going through the PKEY bridge.  I would very much like to see your code
> > to see what's going on. 
> 
> Over on an ntpsec list, Kurt Roeckx reported that he was still waiting...
> 
> Richard's message said "I", so I sent him a copy off list.  Correcting that...

So I took a look at at the EVP_PKEY case, and it seems we spend most
of our time doing:
- alloc/free. 12 alloc and 16 free calls per signature
- OPENSSL_cleanse: 10 calls per signature
- EVP_CIPHER_CTX_reset: 6 calls per signature

Most of the time is spent in those functions.

The manpage documents:
The call to EVP_DigestSignFinal() internally finalizes a
copy of the digest context. This means that calls to
EVP_DigestSignUpdate() and EVP_DigestSignFinal() can be called
later to digest and sign additional data.

And:
       EVP_MD_CTX_FLAG_FINALISE
           Some functions such as EVP_DigestSign only finalise
           copies of internal contexts so additional data can be
           included after the finalisation call. This is
           inefficient if this functionality is not required, and
           can be disabled with this flag.

(A reference to the EVP_MD_CTX_set_flags manpage would have been
useful.)

So after the EVP_MD_CTX_new(), I added an:
        EVP_MD_CTX_set_flags(ctx, EVP_MD_CTX_FLAG_FINALISE);

For me it changed things with 3.0 from:
     AES-128  16 48 16   1696   1.696  475ac1c053379e7dbd4ce80b87d2178e
to:
     AES-128  16 48 16    754   0.754  475ac1c053379e7dbd4ce80b87d2178e

While 1.1 gives me this without the change:
     AES-128  16 48 16    739   0.739  475ac1c053379e7dbd4ce80b87d2178e
and with the change:
     AES-128  16 48 16    291   0.291  475ac1c053379e7dbd4ce80b87d2178e

I question the default behaviour, I think most people don't need
that support.


Kurt