CMAC timings

[Richard Levitte]

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 at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/