Quick forst answer, EVP_MAC_CTX is a typedef of struct evp_mac_ctx_st,
which you find in crypto/evp/evp_local.h. It's quite small (smaller
than EVP_MD_CTX and EVP_PKEY_CTX):
struct evp_mac_ctx_st {
EVP_MAC *meth; /* Method structure */
void *data; /* Individual method data */
} /* EVP_MAC_CTX */;
The slowdown isn't entirely surprising... in pre-3.0, all back-ends
(including engines, with the help of API calls) could reach right into
the EVP_PKEY_CTX that was used by libcrypto code, i.e. central code
and back-end code shared intimate knowledge. With providers, the
boundary between central code and provider code is much stronger,
which means a certain amount of messaging between the two.
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.
Regarding preloaded cipher and key, that tells me that the actual
computation of a MAC is quick enough, that most of the slowdown is
parameter overhead. That was expected.
Cheers,
Richard
On Sun, 14 Jun 2020 17:30:50 +0200,
Hal Murray wrote:
>
> In general, things have slowed down.
>
> The new EVP_MAC code takes 3 times as long as the old CMAC code on 1.1.1.
> The new PKEY code takes twice as long as the old CMAC code on 1.1.1
>
> The one ray of hope is that the API for EVP_MAC has split the part of the
> setup that uses the key out of the init routine. If we can hang on to a ctx
> for each key, we can cut the time in half - that's new ECP_MAC vs CMAC on 1.1.1
>
> So how much memory does a ctx take? How can I find out?
>
> Even if I can't allocate a ctx per key, I can at least keep one around from
> recv to send. That makes the slowdown 1.7 instead of 3.
>
> ----------
>
> Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz
>
> # KL=key length, PL=packet length, CL=CMAC length
>
> # OpenSSL 1.1.1g FIPS 21 Apr 2020
>
> # CMAC KL PL CL ns/op sec/run
> AES-128 16 48 16 366 0.366 475ac1c053379e7dbd4ce80b87d2178e
> AES-192 24 48 16 381 0.381 c906422bfe0963de6df50e022b4aa7d4
> AES-256 32 48 16 407 0.407 991f4017858de97515260dd9ae440b06
>
> # PKEY KL PL CL ns/op sec/run
> AES-128 16 48 16 436 0.436 475ac1c053379e7dbd4ce80b87d2178e
> AES-192 24 48 16 448 0.448 c906422bfe0963de6df50e022b4aa7d4
> AES-256 32 48 16 461 0.461 991f4017858de97515260dd9ae440b06
>
> ---------
>
> # OpenSSL 3.0.0-alpha3 4 Jun 2020
>
> # CMAC KL PL CL ns/op sec/run
> AES-128 16 48 16 973 0.973 475ac1c053379e7dbd4ce80b87d2178e
> AES-192 24 48 16 987 0.987 c906422bfe0963de6df50e022b4aa7d4
> AES-256 32 48 16 1011 1.011 991f4017858de97515260dd9ae440b06
>
> # PKEY KL PL CL ns/op sec/run
> AES-128 16 48 16 817 0.817 475ac1c053379e7dbd4ce80b87d2178e
> AES-192 24 48 16 824 0.824 c906422bfe0963de6df50e022b4aa7d4
> AES-256 32 48 16 842 0.842 991f4017858de97515260dd9ae440b06
>
> # EVP_MAC KL PL CL ns/op sec/run
> AES-128 16 48 16 1136 1.136 475ac1c053379e7dbd4ce80b87d2178e
> AES-192 24 48 16 1153 1.153 c906422bfe0963de6df50e022b4aa7d4
> AES-256 32 48 16 1181 1.181 991f4017858de97515260dd9ae440b06
>
> Preload cipher and key.
> AES-128 16 48 16 170 0.170 475ac1c053379e7dbd4ce80b87d2178e
> AES-192 24 48 16 182 0.182 c906422bfe0963de6df50e022b4aa7d4
> AES-256 32 48 16 196 0.196 991f4017858de97515260dd9ae440b06
>
>
>
> --
> These are my opinions. I hate spam.
>
>
>
--
Richard Levitte levitte@xxxxxxxxxxx
OpenSSL Project http://www.openssl.org/~levitte/
