On Wed, Jun 17, 2020 at 03:50:05AM -0700, Hal Murray wrote:
> levitte@xxxxxxxxxxx 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
