EVP_MAC_init() in 3.0 alpha 13

Hal Murray hmurray at megapathdsl.net
Mon Apr 12 12:48:57 UTC 2021

> Did you attempt to pass NULL for the key and zero for it's length to the
> EVP_MAC_init() call? 


We can do better.  If we have to use dup/free, we can move the EVP_MAC_init() 
to before the dup, out of the timing path.

My model is that initialization is 2 parts.  The first is turning the key into 
a big table.  The second is initializing a small amount of state that is 
whatever is needed/updated by EVP_MAC_update().

I was hoping that EVP_MAC_init() with NULL key would bypass the first step and 
do the second.

If the second step involves a lot of computation we get into the space/time 
tradeoff of computing it during step one and saving it in case EVP_MAC_init is 
called with NULL key.

If there was a copy operation we could use it instead of dup/free.

Where is the code that does the key setup?  I expect it will be obvious after 
I see it, but I don't know my way around that linkage yet.  I'm using the 
default AES-128-CBC.


I don't think I've said it explicitly, but thanks for the change to the API 
for EVP_MAC_init()


Should PKEY be a potentially interesting approach for something like this?  I 
think it was suggested months ago.  One advantage is that the code works with 

It's horribly slow in 3.0

0.777 CMAC
7.533 PKEY
3.323 PKEY preload
0.392 EVP_MAC
0.308 EVP_MAC Preload with dup+free
0.102 EVP_MAC Preload (no dup, wrong answer)

0.285 CMAC
0.550 PKEY
0.196 PKEY preload

These are my opinions.  I hate spam.

More information about the openssl-users mailing list